MergedDictionaries and Resource lookup

Question

i have a problem with Resource dictionaries and mergeddictionaries in general, especially when it comes to resource-lookup performance. After some performance testing i foun

Answer 1

Was any light shed on the resource lookup procedure? Why was "myColor" not found?

By the way, I found a way to make it work - but a strange and unstable way. If Application.xaml has this code, the color should be found:

<ResourceDictionary.MergedDictionaries>
    <ResourceDictionary Source="/ResourceTestLib;component/Themes/Colors.xaml"/>
    <ResourceDictionary>
        <ResourceDictionary.MergedDictionaries>
            <ResourceDictionary Source="/ResourceTestLib;component/Themes/Template.xaml"/> 
        </ResourceDictionary.MergedDictionaries> 
    </ResourceDictionary>
</ResourceDictionary.MergedDictionaries>

If, on the other hand, you include this code into another XAML, which you then include into Application.xaml - it doesn't work, even though the resource structures are identical (verified with Snoop).

Answer 2

I tend to go the route of using only one ResourceDictionary in an application to avoid any performance issues.

To keep the XAML manageable, I use the XAML regions Visual Studio plugin and wrap each category of resources in a region.

• Brushes
• Text Styles
• etc...

For this scenario, the plugin is an absolute life saver. http://visualstudiogallery.msdn.microsoft.com/3c534623-bb05-417f-afc0-c9e26bf0e177

Answer 3

Well I don't like answering my own question, but I guess a lot of people might stumble into this and I want to give them our current solution as an option to consider.

Like I said before, we have a lot of XAMLs, around ~300 for all different kinds of things like Shared Resources (Brushes, Colors) but also many XAMLs containing different DataTemplates, Styles for controls and also for Custom Controls. In the beginning this approach of having a lot of XAMLs was reasonable for us, because we do the same with our classes and keep them small and organized. Unfortunately, WPF doesn't like that. The more ResourceDictionaries you have and the more you merge them via MergedDictionaries the worse your performance will get. The best advice I can give you is, use as few ResourceDictionary XAMLs as possible.

We bit the bullet and merged a lot of them into one giant XAML, in fact we do this now with a pre-compiler keeping the best of both worlds. We can use as many XAMLs as we want, just following a few constraints, and merging them on a compile in a giant XAML. The performance increase we get was remarkable. In my question I wrote "11 million hits on getMergedDictionaries" ... just "precompiling" one of our assemblies, we went down to 2million hits and the performance is in the whole application at all times a lot better.

So in the end. XAML resources should not be considered as source code that gets compiled, instead it should be understand as an actual resource that, when declared, exists, takes up space and performance.

Well we had to learn that the hard way. I hope everyone reading this can improve their projects by learning from our mistakes.

Thanks for all the comments and suggestions.

Best regards Nico

Answer 4

Using SharedResourceDictionary instead of ResourceDictionary completely solved MergedDictionaries performance issue for me: http://www.wpftutorial.net/MergedDictionaryPerformance.html