Does ComponentResourceKey have any use?

[Pavan Podila]

When I am creating custom skins, I generally keep all the resources in a separate dictionary and merge it in generic.xaml. The resources in that dictionary are given standard string-based keys. Later in generic.xaml I directly reference these resources using Static or Dynamic resource. The MSDN doc recommends the use of ComponentResourceKey (CRK) for resources defines in theme dictionaries. However I haven't seen much difference between the two (string and CRK) and both work the same. I am wondering if CRK has any use? Does it have to do with duplication of resources ?

I am curious to know.

--
the approach, rather than the solution
...o0O0o...
http://blog.pixelingene.com

[Mark Smith]

I think the key is that some other thing in the application could be
using the same string for a different resource. CRK solves that issue
by adding the Type information to the key so that the key is
associated to a specific control - even if someone else defines the
same string somewhere in the resource chain it won't actually
conflict. That way you can define string keys like "BackgroundBrush"
without potential conflicts between controls in the same assembly.

[Pavan Podila]

I guess that has to be it, a fully qualified name to reference a resource. Thanks Mark!

[Ian Griffiths]

...also, if I remember correctly, by using a ComponentResourceKey, it becomes possible to access the resource from other resource scopes, e.g. within your application’s UI.

 

If you use strings to name resources in your system-scope resources (i.e. generic.xaml et al, and any dictionaries that they merge in), those resources will only be available from within your own system-scope files. So you’ll be able to access the things by name from within generic.xaml, but if you try to lookup string-named system-scope resources from, say, Window1.xaml, it won’t work.

 

So it’s not merely that using a ComponentResourceKey guarantees global uniqueness, it’s that string-based resource lookups never even try looking in the system scope. (So even if you went out of your way to ensure that all your resources had unique strings names, you still wouldn’t be able to use them.)

 

To find a system-scope resource, WPF needs to know what assembly it’s supposed to look in. So the resource key needs to contain a suitable clue. Using a Type object as a key, as we do with Styles, is one option – WPF uses Type.Assembly to work out where to look. But ComponentResourceKey is the other way – it incorporates enough information for WPF to work out which assembly contains the resource in question.

 

Without that, WPF wouldn’t know where to look – conceptually, the system resource scope includes every DLL accessible to your application. You wouldn’t want WPF to load every DLL in the GAC in the hope of finding your resource...

 

 

--

Ian Griffiths

[Pavan Podila]

Thanks a lot Ian for that detailed explanation. It is certainly one of the features which I haven't explored much. Hope to apply the ideas soon!