The big news about Windows 8 is its new mode based on the Metro design language and UI paradigm. Metro apps are based on the new WinRT (Windows Runtime) and can be built in two distinct ways. One utilizes HTML5 and JavaScript, while the other uses XAML for the user interface definition and C#, Visual Basic, or native C++ as the language behind the scenes. Not surprisingly, the later has often been compared to other XAML-based setups, in particular Silverlight, but also WPF. After all, “XAML is XAML,” the reasoning goes, so it should not be difficult to move both WPF/Silverlight skills as well as actual applications into the new world of WinRT. But is that really so?

To find out, I decided to take a small, yet real-world application and move it from Silverlight to WinRT. Silverlight should theoretically be a close match for WinRT’s XAML, since the paradigms match relatively closely. Both environments are client-side environments that rely heavily on services to retrieve data. Both have limited access to local resources. WPF, on the other hand, follows a different model in allowing developers full-trust on the local machine, which means the entire .NET Framework (potentially even server-side components) could be used directly in WPF applications. This doesn’t mean that WPF’s XAML concepts should not map to WinRT, but Silverlight seemed to be a more promising first step. (I will, however, explore WPF to WinRT conversions further down below as well.)

Theoretic Compatibility

Before I dive into a concrete conversion example, let me spend a bit of time exploring what XAML compatibility really means. I find that a lot of people are confused by the fact that the XAML-label is attached to different technologies. XAML is used for WPF (its original use), but it is also used for Silverlight, Silverlight for Windows Phone, now WinRT, and even non-UI environments such as the Windows Workflow Foundation. Clearly, it is not possible to simply take something written in XAML and just move it from one environment to another and just expect it to work. For instance, if one was to take a random WPF window defined in XAML and try to run it as part of a Windows Phone application, the experiment is doomed to fail for certain (Windows Phone doesn’t use the concept of “windows”), despite the fact that both environments use XAML. Nevertheless, people - especially managers and decision makers with little exposure to the “nitty gritty” - are often lured into ill-advised decisions by an incorrectly conceived belief that “since it is XAML is must be pretty close.” I have even seen people getting confused by the wide range of XAML capabilities within a single environment. Once company I worked with had graphics designers use XAML to define vector images that looked like user interfaces thinking they were building something that would result in working applications. It proved to be a very expensive mistake.

People are often lured into ill-advised decisions by an incorrectly conceived believe that “since it is XAML is must be pretty close.”

So what is XAML really? Many people would be surprised to learn that XAML is NOT a user interface definition language. XAML is simply an object instantiation language that happens to be very useful for user interfaces. Consider the following simple XAML example:

Many people would be surprised to learn that XAML is NOT a user interface definition language.

<Window xmlns="<a href="http://schemas.microsoft.com/winfx/2006/";>http://schemas.microsoft.com/winfx/2006/<;/a>
xaml/presentation"
  xmlns:x="<a href="http://schemas.microsoft.com/winfx/2006/xaml";>http://schemas.microsoft.com/winfx/2006/xaml<;/a>">
  <StackPanel>
    <TextBox/>
    <Button>Search</Button>
  </StackPanel>
</Window>

This is a relatively trivial XAML example that defines a WPF window with textbox and button controls. Anyone familiar with WPF would have little difficulty identifying this code segment as a XAML snippet and the individual XML tags as valid “XAML tags.” But what does that mean exactly? Does XAML really understand what a tag or a