ailon's DevBlog: Development related stuff in my life

Writing WPF/Silverlight compatible code. Part 6: Adding XAML files as links

1/13/2010 5:05:40 PM

Note for future readers: These series discuss WPF and Silverlight versions that are current stable versions at the time of this writing – WPF 3.5 and Silverlight 3.

These are ongoing series of posts on the subject of WPF/Silverlight compatibility. New posts will be added to the Table of Contents post as they are written so bookmark that post or just subscribe to my RSS feed.

While developing WPF/Silverlight applications and controls one of the main code sharing techniques is adding shared code files as links to one of your projects.

Visual Studio - Add As Link

This works perfectly with C# or VB files but not as good with XAML. In this article I’ll show you a workaround to make this technique work with only a small overhead.

The Problem

Suppose you’ve created a WPF project and your own custom control named MyTemplatedControl. It does nothing in our example (just sets DefaultStyleKey property).

   1: public class MyTemplatedControl : Control
   2: {
   3:     public MyTemplatedControl()
   4:     {
   5:         this.DefaultStyleKey = typeof(MyTemplatedControl);
   6:     }
   7: }

Now we create a default ControlTemplate for our control. To do this we add Themes folder to our project and Generic.xaml flie in that folder.


Our template will just display a blue rectangle (just so we can see if it’s applied). Here’s the XAML in Generic.xaml file.

   1: <ResourceDictionary
   2:     xmlns=""
   3:     xmlns:x=""
   4:     xmlns:local="clr-namespace:TestControl"
   5:     >
   7:     <Style TargetType="local:MyTemplatedControl">
   8:         <Setter Property="Template">
   9:             <Setter.Value>
  10:                 <ControlTemplate TargetType="local:MyTemplatedControl">
  11:                     <Canvas>
  12:                         <Rectangle Canvas.Left="20" Canvas.Top="20" Width="100" Height="100" 
  13:                                    Fill="Blue" Stroke="Black" StrokeThickness="3" />
  14:                     </Canvas>
  15:                 </ControlTemplate>
  16:             </Setter.Value>
  17:         </Setter>
  18:     </Style>
  19: </ResourceDictionary>

We add our control to a test window and run the app we see something like this:


Now we want to create a Silverlight version of the control. We create a Silverlight custom control project, “Add As Link” our MyTemplatedControl.cs file, create Themes directory and “Add As Link” our Generic.xaml file. Everything compiles just fine. But when we add the control to a Silverlight application and run it we get an empty white screen. The template is not applied.

This happens because for some reason (I don’t know if it’s done for a reason or is it just a bug) XAML compiler compiles local and linked .xaml files differently. Here’s an article describing what happens. Short story is that resource key for local and linked xaml files are different and since the engine looks for a specific resource key for default styles it just can’t see the linked version because it’s key is not equal to what it looks for.

The Solution

The above mentioned article suggest a workaround of moving all resources to a separate assembly. I’m pretty sure that wouldn’t work with default styles and generally is not something you would want to do in simple scenarios.

I solved this issue using MergedDictionaries. The solution is to move you Generic.xaml content to other XAML file (or even better separate files for each control). This way you can “Add As Link” those specific files and add separate Generic.xaml files with only a list of MergedDictionaries addressing the resource key differences.

Let’s apply this technique to our example. So we move our XAML to a separate MyTemplatedControl.xaml file and reference it from MergedDictionaries in Generic.xaml.


   1: <ResourceDictionary
   2:     xmlns=""
   3:     xmlns:x=""
   4:     xmlns:local="clr-namespace:TestControl"
   5:     >
   6:     <Style TargetType="local:MyTemplatedControl">
   7:         <Setter Property="Template">
   8:             <Setter.Value>
   9:                 <ControlTemplate TargetType="local:MyTemplatedControl">
  10:                     <Canvas>
  11:                         <Rectangle Canvas.Left="20" Canvas.Top="20" Width="100" Height="100" 
  12:                                    Fill="Blue" Stroke="Black" StrokeThickness="3" />
  13:                     </Canvas>
  14:                 </ControlTemplate>
  15:             </Setter.Value>
  16:         </Setter>
  17:     </Style>
  18: </ResourceDictionary>


   1: <ResourceDictionary
   2:     xmlns=""
   3:     xmlns:x=""
   4:     >
   5:     <ResourceDictionary.MergedDictionaries>
   6:         <ResourceDictionary Source="/WpfControl;component/Themes/MyTemplatedControl.xaml" />
   7:     </ResourceDictionary.MergedDictionaries>
   8: </ResourceDictionary>

Now we “Add As Link” MyTemplatedControl.xaml to our Silverlight project and add a copy of Generic.xaml and make required changes.

Generic.xaml (Silverlight project version)

   1: <ResourceDictionary
   2:     xmlns=""
   3:     xmlns:x=""
   4:     >
   5:     <ResourceDictionary.MergedDictionaries>
   6:         <ResourceDictionary Source="/SlControl;component/MyTemplatedControl.xaml" />
   7:     </ResourceDictionary.MergedDictionaries>
   8: </ResourceDictionary>

Notice the differences in Source of ResourceDictionary:

  1. It refers to out Silverlight assembly (SlControl)
  2. It addresses linked XAML file by it’s “incorrect” resource key which is a side effect of linking the XAML file described above (notice that there’s no “Themes” portion in the path)

Now our Silverlight app runs as expected:


This way we can share elaborate XAML between WPF and Silverlight versions (or just between several WPF and/or Silverlight projects) without having to maintain 2 versions of the file. And the only price to pay for this is that we have to add a line to both Generic.xaml files every time we add a new XAML file.

kick it on Shout it

Tags: , ,

blog comments powered by Disqus
Copyright © 2003 - 2018 Alan Mendelevich
Powered by BlogEngine.NET