11

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

Dave Clemmer
  • 3,741
  • 12
  • 49
  • 72
Luke Puplett
  • 42,091
  • 47
  • 181
  • 266
  • 1
    regarding this i can give you two questions with partial answer i asked here. [This](http://stackoverflow.com/questions/6693320/mergeddictionaries-and-resource-lookup) and [this](http://stackoverflow.com/questions/6857355/memory-leak-when-using-sharedresourcedictionary). – dowhilefor Oct 11 '11 at 10:08
  • Good Lord. The last project I worked on, we were clean and organised and then it got slower and slower until we chucked them all in app.xaml! That was SL4, so I assumed WPF would be fine. Yikes, Scoob. – Luke Puplett Oct 11 '11 at 10:17
  • 3
    I'm not really familiar with Silverlight but i guess WPF and Silverlight aren't that different in this regard. It's a shame, i agree, but we managed to work around that. My only wish would be, that this would be better documented. Limitations are acceptable, as long as they are clearly communicated. – dowhilefor Oct 11 '11 at 10:22
  • I completely agree with your last sentence. – Luke Puplett Oct 11 '11 at 10:32
  • I've had a severe issue with startup performance after structuring my resources into various dictionaries, too. Right now I use the app.xaml to merge my various resource dictionaries. If I were to judge performance emotionally (yuck!), I'd say it feels like the more cross-references you have within the resource dictionaries, the slower it gets. – Sebastian Edelmeier Oct 19 '11 at 08:42

1 Answers1

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.

Matthew Walton
  • 9,809
  • 3
  • 27
  • 36
  • I use DesignTimeResources.xaml to merge all the resource dics. This might help you. Otherwise, I don't know how or why they're working! In my experience, it's always seemed a bit hit and miss, maybe sometimes a dependent lib isn't building - I think the whole app needs to be clean and buildable, else all kinds of Hell breaks out. – Luke Puplett Oct 12 '11 at 08:36
  • Sometimes I just think the designer's trying to make my life difficult. I've got to the point where I do almost all my XAML by hand, at least that way I get a good layout which resizes properly instead of being a fixed-size mess like the designer produces by default. – Matthew Walton Oct 12 '11 at 10:32
  • Yeah, I do layout by hand and bindings and resource managing in Blend. I generally make stuff in a mini solution and lift it into the main solution/trunk after. – Luke Puplett Oct 12 '11 at 15:02