I'm having some problems sharing common styles between different projects. Here are my projects:-
"Common" - a class library containing common WPF styles.
"Plugin" - a class library containing a user control (not a custom control).
"Core app" - the core WPF application, which displays the user control defined in "Plugin".
"Common" and "Core app" reside in the same solution, while "Plugin" is in a solution of its own.
Styles in the "Core app" project work fine - it references the "Common" project and has the following in App.xaml:-
<ResourceDictionary.MergedDictionaries>
<ResourceDictionary Source="pack://application:,,,/Common;component/MyStyles.xaml" />
</ResourceDictionary.MergedDictionaries>
When editing XAML files in the "Core app" project, I get intellisense on style names, no squiggly underlines, and everything works fine at runtime too.
The Problem is with the "Plugin" project. I've referenced the "Common" assembly, and created a \Themes\Generic.xaml file containing the same merge XAML as above. Generic.xaml has a build action of "Page", and I've added the following to AssemblyInfo.cs:-
[assembly: ThemeInfo(ResourceDictionaryLocation.None,
ResourceDictionaryLocation.SourceAssembly)]
When I edit the XAML of a user control in this "Plugin" project, styles in the "Common" assembly don't show up in intellisense, and VS/Resharper puts a squiggly line under their names. I've even added a style directly to Generic.xaml, but the UC can't see that either. The user control looks something like this:-
<UserControl ..blah..>
<StackPanel>
<TextBlock Style="{StaticResource AStyleInCommonAssembly}" Text="Hello"/>
<TextBlock Style="{StaticResource AStyleInGenericXaml}" Text="World"/>
</StackPanel>
</UserControl>
At runtime, WPF does correctly apply styles that reside in the "Common" assembly (I guess it's finding them due to the dictionary merge in App.xaml). However it's still unable to find the style that I added directly to Generic.xaml.
What am I missing? Does this approach only work with custom controls, and not user controls as I'm dealing with? My priority is to get things working at runtime, but getting the design-time/intellisense experience would be a bonus.
Solved. It seems that the technique of using generic.xaml only applies to custom controls, not user controls. Styles defined in generic.xaml (directly, or merged from another assembly) are not accessible by a user controls.
After realising this, I just went back to merging the external assembly resource dictionary within the user control itself, i.e.:
<UserControl.Resources>
<ResourceDictionary>
<ResourceDictionary.MergedDictionaries>
<ResourceDictionary Source="pack://application:,,,/Common;component/MyStyles.xaml" />
</ResourceDictionary.MergedDictionaries>
</ResourceDictionary>
</UserControl.Resources>
Not ideal having to do this in each UC, but I can live with it in my scenario as I'll only ever have one or two in these "plugin" projects.
In doing this though, I did uncover another issue, and the following may help someone in the future. The MyStyles.xaml file in my "Common" assembly contains no styles of its own - it simply merges a number of other resource dictionaries in that assembly. This was done for convenience, meaning a consumer only needed to merge in MyStyles.xaml, rather than the dozen or so individual XAMLs in that assembly.
It turns out that there is a bug in WPF whereby "nested" merged dictionaries don't get parsed correctly. I found that if I put a style directly in MyStyles.xaml, the user control would find it. However it refuses to recognise any of the styles in the dictionaries that MyStyles.xaml merges! I've now dropped MyStyles.xaml, and have gone back to merging in the individual dictionaries (from within the user control XAML) - everything works, at design-time and runtime.
You can also define a UserControlBase from which all your UC derive and then merge all your styles in it.
Related
I believe my question is fairly simple and yet I am having difficulty implementing it successfully. I simply wish to extract the styling of elements in my WPF application because the xaml is rather crowded and xaml is often duplicated.
I therefore wish to place the styling in an external xaml file, in the form of a resource dictionary, then reference that file in the resources section of my code.
I have the following .xaml file:
<ResourceDictionary
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">
<Style x:Key="PTextBox" TargetType="TextBox" x:Name="PTextBox">
<Setter Property="Foreground" Value="#FFA1C8E7"/>
<Setter Property="BorderBrush" Value="#FFA1C8E7"/>
</Style>
And I reference the dictionary here:
<UserControl.Resources>
<ResourceDictionary x:Key="PegasusStyles">
<ResourceDictionary.MergedDictionaries>
<ResourceDictionary Source="../../Resources/Styles/PegasusStyles.xaml"/>
</ResourceDictionary.MergedDictionaries>
</ResourceDictionary>
</UserControl.Resources>
Visual studio has resolved the file location so I know this reference is correct.
The text box the styles are applied to then references the style:
<TextBox Style="{StaticResource PTextBox}"/>
If left as a static resource I get a xaml parse error like so:
An unhandled exception of type 'System.Windows.Markup.XamlParseException' occurred in PresentationFramework.dll
And if I make the resource dynamic then the styles simply do not get applied at runtime.
I'm not sure if xaml files require certain properties before run time but mine are as follows:
If someone could answer this mystery it would be wonderful. I googled till my fingers bled but none of the answers posted by others have resolved my issues and this seems very rudimentary.
EDIT: Solved. Switching the build action to Page instead of resource has fixed my issue as suggested by Andrew Stephens. This had been hidden by another underlying problem, which is that I had added a boolean to visibility converter (common tool) to my resources. This alone is fine but once I had declared a resource dictionary this converter needed to be brought inside the dictionary as well.
It sounds like a XAML syntax error somewhere, but can also be caused by an unhandled exception in the main window code-behind (if you have any code in here). There are a few ways to debug this cryptic exception here (read the comments for more tips)
Also the Build Action of your .xaml resource file should be "Page" rather than "Resource".
Try building the solution with your newly merged dictionary before you start referencing the external styles in your xaml.
It may seem counter intuitive but it is possible for visual studio to know about a type in another xaml file without the designer being aware which can cause bugs like this.
Koda
I use a class library (WPF user control library) to host some user controls which other (C#-) applications in the project solution consume. I want these controls to use XAML ControlTemplates residing at the top scope of the class library. The ControlTemplates do not have to be consumed outside the class library.
Here a template declaration:
<ControlTemplate TargetType="{x:Type Button}" x:Key="TemplateImageButtonSmall">
<Grid>
<Image Name="img" Source="/PSCommonUI;component/Images/Buttons/ButtonMinus_normal.png"/>
</Grid>
</ControlTemplate>
Then I have a user control in the class library, containing:
<Button Height="57" Margin="10,0,6,5" Name="button3" Template="{StaticResource TemplateImageButtonSmall}" Width="82">
In an application, I can use the App.xaml file for defining the templates. However, in a class library I don't have this option.
I have searched the web and found some answers including the use of a generic.xaml file, ComponentResourceKey, merging resource files and other stuff I find exaggeratedly complicated.
Also I read that theme definitions (resources in general) shouldn't reside in a class library.
But if I need some themes ONLY in this class library for the there hosted controls, how is best practice then?
Thanks in advance,
Julian
I am not sure what you meant, however, if you want child UIElements from a specific UIElement and below to use control templates, then you can define the templates in a resource dictionary and merge the dictionary into the top control that you want the dictionary to be visible to.
Edit:
The assembly just contains the classes and resources within it. It has no events of its own (e.g. OnApplicationLoaded).
A control's XAML can contain resources of its own (e.g. control templates) for consumption by itself and child controls and thus define default styling.
Your application can merge the resource dictionaries into any level of the tree (application, window, control, ...) and thus override defaults.
If you want the styling to be dynamic (overrable by importing resource dictionaries) then using the DynamicResource keyword your XAML. If your resource is defined in the same XAML and can not be overridden then use the StaticResource keyword.
Add a resource dictionary to your class library and define your resources (templates) there. It doesn't have to be generic.xaml.
Then in each user control or other .xaml file reference the resource dictionaries you require using Xaml similar to:
<UserControl.Resources>
<ResourceDictionary>
<ResourceDictionary.MergedDictionaries>
<ResourceDictionary Source="... path to dictionary 1"/>
<ResourceDictionary Source="... path to dictionary 2"/>
<ResourceDictionary Source="... etc"/>
</ResourceDictionary.MergedDictionaries>
</ResourceDictionary>
</UserControl.Resources>
You can then use resource keys from the merged dictionaries.
Consider a File | New Project of a WPF Application that contains:
A new custom control named CustomControl1
Two new resource dictionaries named Dictionary1 and Dictionary2
Take the generated style out of Generic.xaml and move it to Dictionary2. Then merge Dictionary2 into Dictionary1 and Dictionary1 into Generic like this:
<!--Generic.xaml-->
<ResourceDictionary.MergedDictionaries>
<ResourceDictionary Source="pack://application:,,,/Themes/Dictionary1.xaml"/>
</ResourceDictionary.MergedDictionaries>
<!--Dictionary1.xaml-->
<ResourceDictionary.MergedDictionaries>
<ResourceDictionary Source="Dictionary2.xaml"/>
</ResourceDictionary.MergedDictionaries>
Then, add an instance of CustomControl1 into MainWindow's grid. (This part is necessary to reproduce the issue. The project always compiles fine - only at runtime does the issue show up, and the dictionaries must be referenced.)
In Dictionary1.xaml I am merging in another dict in the same folder, so a simple Source="Dictionary2.xaml" works. Yet in Generic.xaml I must use an absolute URI. If I change the above to be Source="Dictionary1.xaml" without the pack://application stuff then I get a XamlParseException caused by an IOException "Cannot locate resource 'dictionary1.xaml'" when it tries to construct the MainWindow.
My Question: What's special about generic.xaml regarding relative URI resolution, and why?
Excuse me because I have no ability to write comments so I post this as an answer.
I have the same situation and everything works fine for me. I don't need to put "pack://application" in the path in Generic.xaml. But only when the output type of an assembly is "Windows Application".
For "Class library" I need to add assembly name to the path (Source="/ClassLibarayAssemblyName;component/Themes/Dictionary1.xaml") becasue without it WPF engine tries to look for Dictionary1.xaml in application's main assembly.
Target framework in both cases is ".NET Framework 4 Client Profile"
Just a guess: generic.xaml needs to be accessible from outside assemblies as well, so it's a way to ensure that the resources can be found from anywhere, using absolute URIs. As I said, it's just a stab in the dark, not sure.
In my WPF project i keep a user control in a separate library project. The user control accesses resources in a separate XAML file, like this:
<UserControl.Resources>
<ResourceDictionary>
<ResourceDictionary.MergedDictionaries>
<ResourceDictionary Source="/Resources/ViewResources.xaml" />
</ResourceDictionary.MergedDictionaries>
<!-- Local styles here -->
</ResourceDictionary>
</UserControl.Resources>
The resource file, ViewResources.xaml, resides in a folder in the control library project named Resources. It has the default build action (Page) and custom tool (MSBuild:Compile).
The problem is when I reference the control library in my WPF application and use the user control. At runtime, I get the following XamlParseException:
Set property 'System.Windows.ResourceDictionary.Source' threw an exception.
...which wraps the IOException:
Cannot locate resource 'resources/viewresources.xaml'.
How can I fix this? I have tried to change the resource file's build action to "content" and have it copied to the output directory (that works for files and similar "dumb" resources). But to no avail. Also, it doesn't work property in the user control then.
Is there a better way to specify the path?
Will I have to move the resource file to the application project (I'd rather not, as it belongs in the user control's domain).
Found it.
Turns out there is a better way to specify the path, Pack URIs. I changed the XAML to the following:
<UserControl.Resources>
<ResourceDictionary>
<ResourceDictionary.MergedDictionaries>
<ResourceDictionary Source="pack://application:,,,/RoutingManager;component/Resources/ViewResources.xaml" />
</ResourceDictionary.MergedDictionaries>
<!-- Local styles here -->
</ResourceDictionary>
</UserControl.Resources>
and that fixed it.
I thought it was worth posting this just in case anyone else is struggling with the same problem, as I've spent over two hours fighting with syntax, etc. only to find that the solution was dead simple, but not that apparent:
When referencing a packed resource from another control library, it seems to work fine at design time, and even compiles without error, but fails at runtime with the 'Set property 'System.Windows.ResourceDictionary.Source' threw an exception' error. It turns out that simply referencing the resource assembly from your control library is not enough, you ALSO need to add a REFERENCE to the assembly containing the resource dictionary in you main application assembly, else it seems it does not get compiled into the application. (i.e. Startup Application (the one with app.xaml) -> Add Reference -> select assembly with referenced resource file/s).
Hope this helps!
In my case I had the ResourceDictionary and the UserControl on the same Library, but separate from the main application. What worked for me was specifying the name of the assembly in the format Adam suggested in the comment AND I had to change the ResourceDictionary in the project from Embedded Resource to Page. I didn't try using the pack:// format, but I assume it would work too.
<ResourceDictionary Source="/AssemblyName;component/Assets/MyResource.xaml"/>
I had the same error (IOException - file not found), which cost me a day of my life that I'll never get back.
Using neither the simpler "/assemblyname..." nor the "pack://...." syntax worked for me.
I was referencing the resource assembly in my main assembly correctly.
The error disappeared when I changed my xaml resource file Build Action property to "Resource", as mentioned above.
However, I then encountered a XamlParseException at this line:
<ImageBrush x:Key="WindowBackground" ImageSource="Images/gradient.png" />
(which I had hand-typed).
This left the xaml resource file I was trying to include with effectively an invalid dependency.
Oddly the fix was to delete the ImageSource property I had typed, re-insert it BUT select the image from the pulldown menus that appear as a result.
Even though the resulting line appears exactly the same, it clearly isn't.
Starting to dislike WPF (VS2013), but hope this helps.
:0/
I had the same situation, but the Pack URIs didn't help me, I was still getting "Cannot locate resource..." exception in the referencing (executable) project. What helped me, was the setting of my ResourceDictionary files in the custom control library project as Embedded Resource.
This question involves the Visual Studio (2008) WPF Designer's apparent inability to handle the usage of resources located at the App.xaml level if the App.xaml is in a separate assembly from the view.
To simplify the explanation of the problem I have created a test application. This application has two assemblies: View and Start. The View assembly contains a xaml window called Window1, and the Start assembly includes the App.xaml file. The App.xaml file in the Start assembly has its StartupUri set to the Window1 in the View assembly. Neither of these files have code-behinds (aside from the standard constructors and InitializeComponent() call).
The code for this example is as follows:
App.xaml:
<Application x:Class="Start.App"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
StartupUri="pack://application:,,,/View;component/Window1.xaml"
>
<Application.Resources>
<!-- Warning Text Style -->
<Style x:Key="WarningTextStyle" TargetType="TextBlock">
<Setter Property="FontWeight" Value="Bold" />
</Style>
</Application.Resources>
Window1.xaml:
<Window x:Class="View.Window1"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="Window1"
Height="300"
Width="300"
>
<Grid>
<TextBlock Text="This is test text" Style="{StaticResource WarningTextStyle}" />
</Grid>
</Window>
The Window1.xaml file contains a single TextBlock that references the App-level WarningTextStyle. This code works fine at runtime because the Window properly finds the App-level resource; however, at design-time the designer complains that it cannot find the WarningTextStyle.
Does anybody know of a clean and scalable solution to this problem?
My standard approach with large applications is to organize my app-level resources into resource dictionary files, and then merge those dictionaries in the App.xaml. To work around the problem that I've described above I have to merge those resource dictionaries into each view's resources. This seems very inefficient, and if I later add another resource dictionary then I need to merge that new dictionary into every view.
A silver bullet solution would re-direct the designer to find the app-level resources. A reasonable work around would be the merging of the app-level resource dictionaries into each view, but only at design-time. At runtime I would like to avoid merging these dictionaries in every view because of the efficiency issues.
I've tried merging the dictionaries on each view in the view's code-behind constructor, and then wrapping that logic in an if statement that checks the DesignerProperties.GetIsInDesignMode() method; however, the Visual Studio designer does not run the view's constructor - so this approach appears to be a bust.
Does anybody have a better solution or work around?
Can you merge the resource dictionary in your referenced assembly (be it App.xaml or your own resource dictionary) from your main (exe) assembly's App.xaml?
I just had a different idea: use a DynamicResource instead of a Static one. This might introduce a tiny performance hit, but I doubt it would be measurable.