Windows Store-apps: WinRT XAML vs. Silverlight XAML

This post is part of a series about creating Windows Store-apps with XAML and C#. Find the Content of the series here:
Windows Store-apps with XAML and C# blog-series

Last weekend I’ve finished the XAML-chapter of my upcoming book about developing Windows Store-apps with XAML and C#. I want to share the things that you should know about the WinRT XAML – the way I call it here – if you’re familiar with Silverlight or WPF.

The WinRT XAML is much like the XAML we know from Silverlight. But there are some differences in WinRT XAML:

  • the way you use your custom namespaces is different
  • there are some missing things (TypeConverters, Custom MarkupExtensions)

Let’s look at the two parts

Use custom namespaces

There are two ways in XAML to use a namespace:

  • 1:1-Namespace-Mapping
  • 1:n-Namespace-Mapping

Read the difference for both in Silverlight- and WinRT-XAML below.

The 1:1-Namespace-Mapping

Let’s assume you’ve the following class:

To use this class in Silverlight-XAML, you’ve to add an Namespace-Mapping like this

or like this if the CLR-Namespace is in another assembly than the XAML-file containing the Namespace-Mapping below: 

With the Namespace-Mapping the classes from that Namespaces can be used with the chosen alias. The alias is “rocker” in the snippets above, so the WindowsEight-class can be used as below:

In WinRT-XAML you’re using the class in the same way as above, but the way of creating the Namespace-Mapping is different. Instead of using the syntax with “clr-namespace…” you use:

You don’t care if the Namespace UIRocker.Special is in another assembly as the XAML-file or not. This works exactly the same way as the using-directive in C#, where you also don’t care if the Namespace is in another assembly than the .cs-File or not. So, great improvement, but creates a little incompability with Silverlight-XAML.

The 1:n-Namespace-Mapping with XmlnsDefinition-Attribute

The Namespace-Mappings above have been 1:1-Mappings. One XML-Namespace was mapped to one Silverlight/WinRT-Namespace.

In Silverlight-XAML you can create a 1:n-Namespace-Mapping by placing the XmlnsDefinitionAttribute (Namespace: System.Windows.Markup) on your assemblies like this:

Classes out of the Namespaces UIRocker.Special and UIRocker.Mvvm can be used in XAML with one alias by making a 1:n-Namespace-Mapping like this:

Unfortunately in WinRT-XAML there is no possibility for a 1:n-Mapping. The Namespace Windows.UI.Xaml.Markup contains a XmlnsDefinition, but it’s not an attribute, it’s a struct and therefore not usable.

Especially when you create a library with many Namespaces in it, it’s great to use just one alias for the library in XAML. Maybe the next Version of WinRT will contain such a mapping. By the way, first versions of Silverlight also didn’t support 1:n-Namespace-Mappings.

Missing things in WinRT-XAML

There are a few other things that are not in WinRT-XAML or behave differently. Let’s take a look at them.


As XAML is XML, every Attribute contains a string-value. This string-value needs to be converted into the value of the property-type the attribute represents. For primitive types like double, float, int, bool, char etc., the conversion automatically is done by the XAML-Parser (Silverlight and WinRT). Also for Properties of type enum, the XAML-Parser tries to convert the specified string-value into the enum-type of the property. There is also a conversion for some central types hardcoded in the XAML-Parser of Silverlight and WinRT, e.g. the Brush-Type. This conversion allows you to assign a string in XAML where a Brush-Instance is required:

The XAML-Parser takes the “Red”-string, creates a SolidColorBrush with the Color Red and assigns it to the Background-property of the ListBox.

(Excourse to WPF-XAML: In WPF-XAML this conversion is not done by the XAML-Parser, it is done by the BrushConverter-class)

Now if you have properties that are of your own type, let’s look at this works in Silverlight and WinRT. Let’s assume we have the classes below:

In Silverlight-XAML, it is possible to create a Person-instance as below if a TypeConverter for the Address-type exists:

The corresponding typeconverter could look like this:

The only thing that is additionally required is to tell the XAML-Parser where to find the AddressConverter. You do this by specifying the TypeConverterAttribute either on the Address-Property in the Person-class or on the Address-class itself. Below an example that specifies it on the Address-class.

So far to Silverlight-XAML, now let’s look at WinRT-XAML. As mentioned above, WinRT-XAML also supports conversion for

  • primitive Types like bool, char, double, int, float,…
  • enumeration-values
  • central types like e.g. the Brush-type.

If you’ve custom types like the Address-class, currently there’s no support. There’s no TypeConverter in WinRT. Dot.


In Silverlight-XAML it’s possible to create custom subclasses from MarkupExtension and use them in XAML with curly braces. WinRT doesn’t support custom Markup-Extensions. Dot.

Did you find out other bigger differences about XAML?

See you next week with the next post about WinRT and Windows Store-apps.


9 thoughts on “Windows Store-apps: WinRT XAML vs. Silverlight XAML”

  1. Hi!

    Tolle Infos! Ich bin gespannt auf das Buch!
    Wird es eine Vorabversion des Buches geben? Und wenn ja, wie kann man sich dafür registrieren bzw. kann man als “Beta”-Leser sich irgendwo anmelden?

    Viele Grüße


  2. It is so disappointing to see that Windows RT is again an INFANT development framework.

    Silverlight was finally coming of age, it was finally becoming ALMOST functional for SERIOUS software, then they kill it. You would think microsoft would learn from its mistakes and at least create something that would continue where they left of with Silverlight… No such luck…

    WINRT… not for me, i’m sorry, i’ll come back in a few years just like i did with Silverlight and hopefully they will not kill it again, just like with Silverlight.

    Microsoft is canibalizing their developer base and they don’t even realize it. I used to really love developing with Microsoft tools. But they have really screwed up this time.

    1. Hi Peter,

      yes, I can understand your opinion and you’re not alone with that one. I think from a developer-point of view it’s not as bad as it seems, because you can continue using XAML and C# like you did in WPF and Silverlight. There are some minor changes like mentioned in this blog-post and there are some WinRT-Types and design-principles to learn. That’s it. :)

Comments are closed.