Blend, WPF and resource references

A number of people have sought more clarity around how Blend and resources references work inside WPF projects. Hope the following FAQs would help with some of your questions.

a) Should I use Static or Dynamic resource lookup?
Blend def. plays better with dynamic resource lookups. You could use a static resource lookup as long as the resource was not located or merged into App.xaml. People have raised concerns around performance issues with dynamic resource lookups (you pay for what you get). While that might be true, an interesting data point is that the Expression Blend source code uses a ton uses dynamic resource lookups for our own UI (of course, we too use static resource lookups in places where the resource would never change, or where it not possible to use a dynamic resource extension, for example non-DPs).

b) If I had to used a static resource lookup, why don't things work when the resource is located in App.xaml?
When a static resource lookup is done inside the Blend design surface, unfortunately, the resource ends up being looked inside the Application object of Blend (which is in itself a WPF application). This does not play well with the way we host the design surface - we don't want to merge the user resources into the Blend Application object to avoid conflicts with the Blend UI styles. Please be assured that solving this problem is pretty high our wish list (and we are working with the WPF team on a solution).

P.S.: If you do run into this issue, the most common symptom is that an exception is thrown on the design surface when you try to instantiate your control which reads something like - XamlParseException - Cannot find resource named '{Blah}'. Resource names are case sensitive...."

c) How can I create a control library of resources and use those resources in a different project?
Here is an example solution that shows you the setup.

d) What is a recommended pattern for organization of resources into external resource dictionaries?
Where there is no single pattern that I have noticed and it really depends on your scenario, an interesting data point is that the Blend source code itself only consists of a few resource dictionaries - we have one for a bunch of colors and brushes, and one for the styles for the common controls we use in our UI. Of course, we have two sets of these - one each for the Expression Dark and Light themes. Of course, fewer number of resource dictionaries helps with better performance inside Expression Blend.

e) What if I was instantiating resources from code? How can I make my application more design-time friendly?
Here is a blog post that might help.

Comments (8)

  1. Gautier Boder says:


    Regarding the point c) of your post which is quite exactly what we’re trying to achieve within our developer / designer team.

    In the example you provide it’s possible to list the RedBrush brush within the application project and to select it as a brush for the Window’s Background property. This is really handy for our designers as they can just select and use styles, brushes and so on.

    However we would prefer to simply distribute an assembly rather than the whole style & brushes project with its sources. This works, we can merge the resource dictionary from the DLL with the one of our application using the pack URI.

    Then we can manually type styles’ and brushes’ name in the XAML and it works well within designer and runtime.

    However what we can’t do is browse, preview and pick all the styles and brushes (from the resources panel) that are stored within that particular DLL as we can do when we link the full project source as you do in your example.

    Are we doing something wrong or is it a "bug" or missing part of Blend 3 (v3.0.1927.0) code? We would really like to have a feedback from you or your team about this point.

    Thanks a lot for your work, Microsoft is on the right way to split designers’ job from developers’ and expression products provide already a strong improvement in this collaboration.

    Gautier Boder, SwissTiming.

  2. Hi Gautier,

    Unfortunately, that is not something we can support easily (without access to the project reference, it is not possible for us to enumerate the resources and liste them out, support renaming, etc.). Would it be possible for you to supply a design-time only resource dictionary to help the designer inside Blend using method e)?



  3. John says:

    Has any of this resource madness been fixed for Blend 4? I’ve wasted many hours trying to work around this issue without success. Your guidance is to use DynamicResource instead of StaticResource, yet it doesn’t appear this is possible when using BasedOn in a style. For example:

    Defined in a Resource Dictionary and merged in App.xaml:

    <Style x:Key=MyStyle TargetType="{x:Type Label}">



    Defined in a UserControl.Resources section:

    <Style x:Key=MyDerivedStyle TargetType="{x:Type Lable}"

             BasedOn="{DynamicResource MyStyle}">



    Blend complains that DynamicResource is not allowed in this scenario, yet if you use StaticResource, it can’t find it within a UserControl. It’s a catch-22. The only way that I can make Blend happy is to declare all UserControl styles the UserControl.Resources section without using a ResourceDictionary. Needless to say, this makes ResourceDictionaries rather useless.

  4. Unni - MSFT says:

    No, unfortunately, we were not able to address this issue for Blend 4.

    (This scenario works just fine for Silverlight projects, and does not work for WPF projects)

  5. Jack says:

    How come this does not cause a problem in the VS2010 designer? App.xaml resources work just fine. VS2010 is a WPF app.

    This bug is still a real pain

  6. Adam says:

    Has there been any updates on the StaticResource bug?  I wasted half of today figuring this one out.  I'm using Blend 4.

  7. Ibrar says:

    What about UserContols that get embedded into other controls and windows? How do we handle static resource lookups in merged dictionaries?…/how-to-resolve-design-time-static-resources-in-embedded-usercontrols-in-blend-4

Skip to main content