Managing WPF Resources (brushes etc.)

Question

Normally, I put what I consider the constitutional root resources, such as brand colours/brushes, fonts and sizes down in the 'distrib' assembly.

The Distrib assembly|ies are designed to go out to 3rd party dev shops, so they have access our contracts, interfaces, and branding styles.

More complex resources are then built up and declared 'nearer' where they're used.

I've come along to an application that has grown organically, err, haphazardly. What's odd is that the modules use resources from the main app executable project, even though the modules don't reference the app.

I assume that because they're 'importing' all the resources into App.xaml, they're available to the psuedo-runtime designer context.

My question is

If this is how MS designed it to work, have I been doing it wrong all along by managing resources like I do a type system?

Thanks

Luke

** UPDATE **

So, it was pointed out to me that well organised resources are not the way to go in WPF due to a severe performance problem (much as I had found in a big SL4 app I worked on, but assumed it was an SL thing).

Assuming that managing resources in this highly organised way can still be done with a trick or two, and that modular systems often need to merge dictionaries, I began to look into using Christian Moser's SharedResourceDictionary solution, but I get a problem at design time only:

System.IO.Packaging.PackUriHelper

The URI prefix is not recognized.
   at System.Net.WebRequest.Create(Uri requestUri, Boolean useUriBase)
   at System.Net.WebRequest.Create(Uri requestUri)
   at MS.Internal.WpfWebRequestHelper.CreateRequest(Uri uri)
   at System.Windows.ResourceDictionary.set_Source(Uri value)
   at CompanyName.Presentation.SharedResourceDictionary.set_Source(Uri value)

It looks like it doesn't understand the pack Uris, which is odd since the SharedResourceDictionary just calls down to the original MS implementation in ResourceDictionary, and registering the pack URI scheme statically doesn't help either!! Grrr.

So I need to crack on and the second option is to smash everything into App.xaml and avoid merged dictionaries.

This means fewer controls/views, and setting up a design-time dictionary in my distributable library which I guess does the job of the app.xaml which they won't have access to.

I think that makes sense.

Interesting? Tell Microsoft

It may be for Silverlight, but I'm hoping the WPF folks might be listening, or at least it might fix one platform -- I've added an 'idea' to the UserVoice site that you can vote up.

http://dotnet.uservoice.com/forums/4325-silverlight-feature-suggestions/suggestions/2307678-fix-the-mergeddictionary-perf-problem

Answer 1

Yes, the App.xaml thing seems to be kind of how it's 'supposed' to work, although obviously other ways are possible as you've found. The performance problem is irritating though, and the App.xaml way is also irritating because they don't resolve at design time (at least, they don't for us, if they do for you I want to know why).

However, putting them in App.xaml is the only technique I've found anything approaching an 'official' statement about.