#GIS from a .NET developer's perspective

WPF vs. Silverlight - Part 10 - XAML Parser Differences

See intro blogpost here.

The XAML parser for WPF and Silverlight are not one and the same, and this also means that there (for whatever reason) are differences in how they interpret the xaml (as kinda hinted at in part 7).

MSDN has a pretty good description on those differences, so I won’t repeat the entire thing (please go read it!), other than point to a couple of important items:

  • Silverlight 4 introduces a XAML parser that behaves differently than Silverlight version 3 and is closer to the WPF XAML parser implementation.  Silverlight includes a XAML parser that is part of the Silverlight core install. Silverlight uses different XAML parsers depending on whether your application targets Silverlight 3 or Silverlight 4. The two parsers exist side-by-side in Silverlight 4 for compatibility. (read: You are more likely to hit issues porting an SL3 app to WPF than from SL4)
  • In some cases, the XAML parsing behavior in Silverlight differs from the parsing behavior in Windows Presentation Foundation (WPF). WPF has its own XAML parser (read: We made a new XAML parser for Silverlight, and cut some corners...)
  • Object elements inside a ResourceDictionary in Silverlight may have an x:Name instead of or in addition to an x:Key. If x:Key is not specified, the x:Name is used as the key. (read: Always use x:Key since this works in both)

Most of the other differences are things supported only in WPF, which is to be expected since Silverlight is a subset. Again this is why I recommend starting with Silverlight and then porting to WPF.

Other things worth noting:

WPF v3.5 does not have a VisualStateManager. Silverlight “invented” this and WPF 4 added it. If you build for WPF 3.5, you can use the WPFToolkit, which adds this support to 3.5.

Compiler conditionals in XAML

As demonstrated in many of the previous parts, you can use compiler conditionals in code-behind (ie. #if SILVERLIGHT...) to write code specific to the platform. Unfortunately you don’t have that luxury in XAML. If you need to have different xaml for the different platforms, I haven’t found a way around duplicating the entire piece of XAML in each project. So no, this won’t work Sad smile :


Next: WPF vs. Silverlight - Part 11 - Silverlight on Phone vs. Browser

WPF vs. Silverlight - Part 9 - Reusing code in Visual Studio #2

See intro blogpost here.

In the previous post, I covered how to configure your project to create both a Silverlight and a WPF build. However, I usually like to structure my control libraries slightly different, and place the theme file for a specific custom control next to the control code, instead of having an ever-growing Themes\Generic.xaml file with all the controls merged together. It makes it easier to find the theme for a specific control without having to scroll an enormous XAML file. My Silverlight project will usually look like this:


In Generic.xaml I instead “merge” in this file using a Merged Dictionary:

        <ResourceDictionary Source="/MyLibrary;component/Controls/TemplatedControl1.Theme.xaml" />

As you add more controls, you simply add another entry into the resource dictionary. So the next step would be to link this new TemplatedContro1.Theme.xaml file into WPF, and make your solution look like the following:


However, this won’t work in WPF! When you run the WPF version, the template will never get applied, because the template is never found. There seems to be a bug in WPF that the Silverlight and Windows Phone compilers doesn’t have, and it literally took me forever to find this problem: WPF doesn’t like linked resource files that isn’t located in the root of the project! The only workaround I’ve found so far is to move the TemplatedControl1.Theme.xaml to the root of the WPF project (still linked though) and create a new non-linked Generic.xaml file for WPF (since it now has to point to a different location of the theme file).

So your WPF project will instead look like this:


Note that the WPF\MyLibrary\Themes\Generic.xaml is no longer linked, but is a copy of the Silverlight file, with the \Controls\ part removed from the ResourceDictionary Source path.

By the way, if you followed the same steps for creating a Windows Phone 7 project, the WP7 compiler doesn’t have this problem so this workaround is specific for WPF only.

Next: WPF vs. Silverlight - Part 10 - XAML Parser Differences

WPF vs. Silverlight - Part 8 - Reusing code in Visual Studio #1

See intro blogpost here.

So now that you know several of the code differences between Silverlight and WPF, how would you set this up in Visual Studio? You could create two projects and copy the code over from one to the other, but then you would have to maintain two sets of code. There’s an easier way:

Create two new Class Library projects in VS2010. One for Silverlight and one for WPF. I recommend calling them the exact same (I know some people like to add WPF or SL to the name to distinguish them, but that forces other libraries that uses them to be different so don’t do that!). If you need one for Windows Phone 7 as well, simply repeat the steps for WPF coming later...




Note that VS will balk at you for naming the project the same. For now just call it for instance “MyLibrary2” or something.

Next in the solution explorer, create a Silverlight and a WPF folder, and move the projects to these. You can now rename the WPF project so it’s called the same. Also go into the project settings and remove the “2” from the assembly name and default namespace. Lastly deleted the default classes that were created for you, as well as the Generic.xaml file in WPF.

image image

OK we are all set. We have two empty projects. One for WPF and one for Silverlight.

In Silverlight add a new “Silverlight Templated Control” item. You now have a custom control in Silverlight. We could copy this to WPF, but instead we’ll link it over. Right-click WPF\MyLibrary, and select “Add existing item”. Browse to the class you added to silverlight, but DON’T click the add button. Instead click the little down-arrow next to the add button and pick “Add as link”.

image image

Repeat the same step for the Generic.xaml file.

Notice in the solution explorer that the “TemplatedControl1.cs” icon in WPF has a little arrow in the lower left corner? This means this is not really located in the WPF\MyLibrary folder, but is pointing to the file in the Silverlight folder.

Now it’s time to remember what was covered in “Part 1”. Add the following code to the new control:

    static TemplatedControl1()
            new FrameworkPropertyMetadata(

Also put the “this.DefaultStyleKey…” in a SILVERLIGHT conditional.

Your code should now look something like this:


For the most part, from here on the code you write for your Silverlight control, should work in WPF. If you hit a difference between the two or want to enhance the WPF version with WPF specific features, use the conditionals as shown above.

This blogpost will continue in the next part with some interesting file-link bugs in Visual Studio you need to be aware of.

Next: WPF vs. Silverlight - Part 9 - Reusing code in Visual Studio #2

WPF vs. Silverlight - Part 7 - Case sensitivity

See intro blogpost here.

Silverlight in general seems less restrictive when it comes to your XAML. For instance case sensitivity. I was recently trying to use a class modifier on my UserControl using the following:

<UserControl x:ClassModifier=”Internal>

However this doesn’t work in WPF. It turns out that the "internal" keyword must be lower-case in WPF. Luckily this also works in Silverlight, so stick with the right casing and you’re good :-)

Next: WPF vs. Silverlight - Part 8 - Reusing code in Visual Studio

WPF vs. Silverlight - Part 6 - Debug.WriteLine

See intro blogpost here.

I often use System.Diagnostics.Debug.WriteLine to write out values or warnings that I or the developer should be aware of, but not necessarily is an error. However, Silverlight has an overload WPF doesn't have (hey I thought Silverlight was only a subset of WPF?!? - well... if it were we didn't need this blogpost serie).

Here are the overloads in Silverlight:

    public static void WriteLine(object value);
    public static void WriteLine(string message);
    public static void WriteLine(string format, params object[] args); //NOT IN WPF! 

and WPF: 

    public static void WriteLine(object value);
    public static void WriteLine(string message);
    public static void WriteLine(object value, string category);
    public static void WriteLine(string message, string category); 

Notice that the 3rd method in Silverlight which is equivalent of using string.Format, doesn’t exist in WPF. Therefore it's safer to use WriteLine(string.Format(format,args)) instead which works in both.

Next: WPF vs. Silverlight - Part 7 - Case sensitivity

WPF vs. Silverlight - Part 5 - XAML Control Instantiation

See intro blogpost here.

Take a look at the following XAML:

    <UserControl Loaded="UserControl_Loaded">
        <my:MyControl Loaded="MyControl_Loaded" />

Can you guess in what order the following events and methods will be triggered when the XAML loads:

    - UserControl.Constructor
    - MyControl.Constructor
    - UserControl.Loaded event
    - MyControl.Loaded event
    - MyControl.OnApplyTemplate method

Come on... just guess...
The gotcha here is that it will be different for Silverlight and WPF!

Silverlight WPF
UserControl.Constructor UserControl.Constructor
MyControl.Constructor MyControl.Constructor
MyControl.Loaded event MyControl.OnApplyTemplate method
UserControl.Loaded event UserControl.Loaded event
MyControl.OnApplyTemplate method MyControl.Loaded event

Notice how OnApplyTemplate for the custom control fires before the Loaded events in WPF whereas in Silverlight if fires after. Therefore if you have code in OnApplyTemplate)() that relies on the the Loaded event having fired first, this probably won't work in WPF (nevermind the fact that your code is probably poorly designed if that's the case :-). Also note that the order the two loaded events fires are opposite.

This is also documented on MSDN:

The timing of the Loaded event in Silverlight differs from the timing of the FrameworkElement.Loaded event in WPF. Specifically, the WPF Loaded event occurs after the template is applied. In Silverlight, the Loaded event is not guaranteed to occur after the template is applied

A workaround for this is also suggested here:

Next: WPF vs. Silverlight - Part 6 - Debug.WriteLine

WPF vs. Silverlight - Part 4 - Animations

See intro blogpost here.

If you want to work with animations programmatically, and modify them as they run, WPF requires you to start and stop the animation with a few extra parameters, to prevent them from being "frozen". Silverlight doesn't freeze elements, so this is not necessary there.

    myStoryboard.Begin(element, true); //true allows for changing animation later
     myStoryboard.Stop(element); //element parameter required when Begin was called with element

Next: WPF vs. Silverlight - Part 5 - XAML Control Instantiation

WPF vs. Silverlight - Part 3 - Creating Bitmaps Programmatically

See intro blogpost here.

WPF Requires you to call BeginInit and EndInit before and after setting the source. Also the load failed handlers are different.

    BitmapImage bmi = new BitmapImage();
    Image img = new Image();
    bmi.UriSource = new Uri(strUrl, UriKind.Absolute);
    img.ImageFailed += img_ImageFailed;
    bmi.DownloadFailed += bmi_DownloadFailed;
    Image myImage = new Image();
    myImage.Source = bmi;

Next: WPF vs. Silverlight - Part 4 - Animations

WPF vs. Silverlight - Part 2 - XamlReader

See intro blogpost here.

XamlReader has different overloads in WPF and Silverlight. Silverlight takes a string. WPF takes a stream to a string.

    UIElement element;
    element = XamlReader.Load(xaml);
    using (MemoryStream xamlStream = 
        new MemoryStream(UTF8Encoding.Default.GetBytes(xaml)))
        element = XamlReader.Load(xamlStream);

Next: WPF vs. Silverlight - Part 3 - Creating Bitmaps Programmatically

WPF vs. Silverlight - Part 1 - Custom Controls Theme

See intro blogpost here.

When applying default theme and template to custom controls that you declared in "/Themes/Generic.xaml" it's done differently in Silverlight and WPF:

public class MyControl : Control
    public MyControl()
        this.DefaultStyleKey = typeof(MyControl);
    static MyControl() {
            new FrameworkPropertyMetadata(

Also, in the WPF Assembly, you need to register the theme file in AssemblyInfo.cs This is done with the following line of code:

[assembly: ThemeInfo(ResourceDictionaryLocation.None,ResourceDictionaryLocation.SourceAssembly)]

Note: This code is usually added automatically when you create a new WPF project.

Next: WPF vs. Silverlight - Part 2 - XamlReader