Merged Resource Dictionaries

As an application grows, keeping every brush, style, and template in one giant ResourceDictionary becomes unmanageable, so XAML provides the MergedDictionaries collection, which lets a top-level ResourceDictionary pull in the contents of several separate dictionary files as if they were all declared inline. This encourages splitting resources by concern, for example a Colors.xaml file for palette brushes, a Typography.xaml for font-related styles, and a Controls.xaml for control templates, all merged together at the Application level.

When two merged dictionaries define an entry with the same key, the dictionary listed later in the MergedDictionaries collection wins, and any resources declared directly in the parent ResourceDictionary (outside of MergedDictionaries) take precedence over all of the merged ones. This last-in-wins rule is what makes theme overriding practical: a base Light.xaml can be merged first and a DarkOverrides.xaml merged second to replace only the keys that need to differ.

A ResourceDictionary's Source property can point outside the current project using a pack URI of the form /AssemblyName;component/Path/File.xaml, which lets a shared component library ship its own default styles and have consuming applications merge them in without copying XAML files around. This pattern is exactly how custom control libraries provide a Generic.xaml with default templates that WPF automatically merges when a themed control is first used.

Every dictionary listed in MergedDictionaries is parsed and its resources instantiated when the parent dictionary loads, so merging dozens of small files at the Application level adds startup cost even for resources a given screen never uses. A common mitigation is to merge only shared, always-needed resources at the Application level and merge page-specific or rarely used dictionaries locally within the Page or UserControl that actually needs them, so their parsing cost is deferred until that page is navigated to.