External global and named Styles not displaying in Blend at design time RRS feed

  • Question

  • First, I've created a DLL for storing all my Styles, ControlTemplates, and other resources like brushes and fonts.  This DLL does NOT contain any custom controls, that is within another assembly.  This assembly is strictly for control styles.  Now, I've set up this project where every control is basically encapsulated into one XAML file that is a ResourceDictionary for ease of organization.  Button.Base.xaml, TabControl.Base.xaml, Button.Green.xaml, etc. 

    Now, in the root of this project is a single file named Default.xaml, which does nothing more than merge all the resources together.  I have done this for a couple reasons; 1) I can merged the Default.xaml file into the Application.Resources merged dictionaries with essentially one line of code.  2) If we ever get into skinning the application, with some simple changes in brush resources, then I can create another root file called Green.xaml or Red.xaml, you get the point.  Then when the application starts up, code can determine which root XAML file to merge into the application's resources.

    Example of Default.xaml in the UI.Resources.dll

        <ResourceDictionary Source="Resources/Styles/Brushes.Controls.xaml" /> 
        <ResourceDictionary Source="Resources/Styles/Brushes.Shared.xaml" /> 
        <ResourceDictionary Source="Resources/Styles/Button.Base.xaml" /> 
        <ResourceDictionary Source="Resources/Styles/Button.Green.xaml" /> 
        <ResourceDictionary Source="Resources/Styles/CheckBox.Base.xaml" /> 
        <ResourceDictionary Source="Resources/Styles/Typography.Base.xaml" /> 

    And then in the app.xaml file of your WPF application:

        <ResourceDictionary Source="pack://application:,,,/UI.Resources;component/Default.xaml" /> 

    I'm trying to move our teams into a Designer/Developer collaboration model.  Currently we are in the Designer/Integrator/Developer, where I am the Integrator (a senior-level developer with a design background).  I take the designer's concepts (from either Blend or PS or AI) and build out control styles; global styles for the core set and then a bunch of named styles for variations.  The developers just add a Button or CheckBox to their XAML, maybe reference a StaticResource Style, and presto.  However, developers are not great at making screens look good, and they shouldn't be concerned with that.  Thus, WPF and the separation of UI/UX from Business logic.  I am trying to get our designers to move into the Blend world and start building screens so the developers don't have to worry about laying out pixel perfect visuals.  Thus, the problem...

    I've set up a project in Blend to 1) reference the UI.Resources.dll, 2) merge the resources the same way we do in the application (see above).  When you create simple window that has nothing more than:


    ...and then run it, it looks correct and displays our custom style button.  However, in the Blend designer window you still see the standard Windows/WPF button visuals, the project compiles successfully, and you get some errors in app.xaml stating things like "cannot locate resource typography.base.xmal."

    How do you get Blend to show the correct visuals from the gloabl styles during design time? 

    I have got this working, but only by copying over all the individual control style files into the project which turns them into "local" resources.  This is a problem because 1) anytime an update to a Style or ControlTemplate is made, or a new Style is added, there's more work for the designer to maintain these files rather than just replace the DLL. 2) I have several XAML files (50+) and I've noticed that Blend really starts dragging when you add all these into the merged dictionaries collection.


    Thursday, November 6, 2008 5:43 PM

All replies

  • At run-time, I am able to wire up the DataContext for a user control using a very simple StaticResource (e.g. CLR object with one property) defined in App.xaml and everything works great as expected.

    However, at design-time in Blend 3, the user control displays an error saying the resource cannot be found. I believe this was also a bug in previous versions of Blend which is why I am so surprised to see it still exists in Blend 3.

    Please see here for the same bug report from a year ago:

    I agree with this user -- this is a *critical* bug. It requires me to jump thru hoops to get both run-time and design-time data working. My only choice is to define my object as a local StaticResource, which is not intuitive or desirable in many situations.

    Tuesday, March 31, 2009 12:14 AM
  • Unfortunately, this bug (where the resource is located in App.xaml and is referenced used StaticResource extensions) cannot be fixed for WPF with a fix to the framework. We are tracking this as an important issues. Your only possible workarounds are to use a dynamic resource where possible, or not run the code when running inside a design tool.

    This problem does not exist in Silverlight applications.

    Wednesday, April 1, 2009 6:29 AM
  • Hi Brett,

    I do recommend that you don't follow the pattern of having a very large number of resource dictionaries - you are right in the fact that things might get slow if you have such a large number of resource dictionaries.

    About your problem of being able to resolve styles - I would have expected that to have worked. What happens if you have project to project referneces to the UI.Resources project from the project where you are consuming them - does that work? What happens if you were to use a URI like <ResourceDictionary Source="/UI.Resources;component/Default.xaml" /> 

    This might just be a bug - if you could send me a repro at unnir at microsoft dot com, I can take a look.

    Also, you might be interested in this technique just as an FYI - http://blogs.msdn.com/expression/archive/2008/04/09/creating-a-wpf-blend-project-that-loads-resources-in-code.aspx

    Wednesday, April 1, 2009 6:38 AM
  • I just wrote a blog post to collect this set of issues so we have a common place to reference these and to come up with best practices.


    I would be happy to add more issues that people want to see clarity around.

    Wednesday, April 1, 2009 7:32 AM