Tag Archives: winrt

Hello World, WinRT !

Now that the mysterious WP7 app I was working on for the last few months is done (at least v1.0!) and is in the certification pipeline, I finally have some time to start playing with WinRT.

Of course, the first thing I’m playing with is the port of this WP7 app to WinRT. In this post, I’m sharing the aspects I discovered this afternoon while trying to port one of the project from Windows Phone to WinRT. Let’s be clear my goal was just to see what it’s look like to port the code, I wasn’t able of course to port the WP7 app to WinRT in an afternoon…


The development environment for Windows 8 is currently:

  • Windows 8 Consumer Preview
  • Visual Studio 11 Beta
  • Blend for Visual Studio Beta

Because I wanted to have the Windows Phone environment too on this machine, I also installed:

The WP7 app currently uses various libraries (all of them are described in this blog post), today I just downloaded the Windows 8 version of MVVM Light (thanks Laurent).

Hello, World

As a developer, one of the first thing we try when we target a new platform is to display some kind of message on the screen. So I first tried the famous MessageBox.Show() but I quickly realized the API has changed… If you want to display a message box, you must use the MessageDialog class:

MessageDialog dialog = new MessageDialog("Content", "Title");
// execution continues here immediately after showing the dialog

As you can see, displaying the dialog is actually an asynchronous operation. If we want to perform an action when the dialog closed, we must await that call:

MessageDialog dialog = new MessageDialog("Content", "Title");
await dialog.ShowAsync();
// execution continues here when the dialog closes

If you want to display additional buttons, you can add commands to the dialog:

MessageDialog dialog = new MessageDialog("Content", "Title");
dialog.Commands.Add(new UICommand { Label = "test" });
IUICommand result = await dialog.ShowAsync();

Namespace changes

Many namespace has changed between Windows Phone and WinRT, you can use pre-processor directives like the following

using System.Windows.Data;
using Windows.UI.Xaml.Data;


Another thing I noticed is the fact that the IValueConverter interface has changed (notice the last parameter…)

WPF/Silverlight/WindowsPhone version (documentation):

public interface IValueConverter
    object Convert(object value, Type targetType, object parameter, CultureInfo culture);
    object ConvertBack(object value, Type targetType, object parameter, CultureInfo culture);

WinRT version (documentation):

public interface IValueConverter
    object Convert(object value, Type targetType, object parameter, string language);
    object ConvertBack(object value, Type targetType, object parameter, string language);


The storage story in WinRT can be summarized by the following:

  • file system access is heavily restricted (this was already the case for Silverlight and Windows Phone)
  • most storage API are asynchronous

Here is an example taken from the WinRT documentation:

// write a file
async void WriteTimestamp()
    StorageFolder localFolder = ApplicationData.Current.LocalFolder;

    StorageFile sampleFile = await localFolder.CreateFileAsync("dataFile.txt", CreationCollisionOption.OpenIfExists);
    await FileIO.WriteTextAsync(sampleFile, DateTime.Now.ToString());

// read a file
async Task ReadTimestamp()
        StorageFolder localFolder = ApplicationData.Current.LocalFolder;

        StorageFile sampleFile = await localFolder.GetFileAsync("dataFile.txt");
        String timestamp = await FileIO.ReadTextAsync(sampleFile);
        // Data is contained in timestamp
    catch (Exception)
        // Timestamp not found


The WP7 app contains several resource files (.resx). The resources are available in the XAML (using a binding to a static resource) and in C# using the static types that are automatically generated with the resx file. Well, it looks like those static types do not exist anymore in WinRT (also, the extension of the resource file has changed to .resw).

The resources can now be accessed using the ResourceLoader type:

res = new ResourceLoader("PrototypeZero/AppResources");
string value = res.GetString("StringKey");


I think .Net developers should not be afraid by WinRT. If you already start playing with C# Async you will be familiar with the new asynchronous API. As far as I’ve gone with the comparison I think we can reasonably imagine having a good code base shared between WinRT and Windows Phone. I can safely continue to use the XAML knowledge I got about 5 years ago on WinRT 🙂

Of course there are many other things we can compare between WinRT and Windows Phone… This first post is just the beginning 🙂

MVVM framework explorer updated !

After several requests, I finally took the time to update my MVVM Explorer Silverlight App !

Here is the changelog:

  • update all download stats (based ONLY on CodePlex stats)
  • refresh popularities
  • remove StructuredMVVM (not available on CodePlex)
  • add WinRT support (however, no toolkit seems to support if official yet)
Top 5 (most downloaded & supporting WPF, Silverlight and Windows Phone):
  1. MVVM Light (95k downloads)
  2. Caliburn Micro (27k downloads)
  3. nRoute (22k downloads)
  4. Simple MVVM toolkit (10k downloads)
  5. Catel (8k downloads)

As always, feedbacks are welcome !

BUILD: WinRT, Silverlight, WPF, XAML

This blog post is part of my BUILD series.

I’m having a very busy week here in Anaheim ! I’m meeting many new people and had the chance to enjoy the conference from the inside. I’m also playing with this new Windows 8 slate Microsoft gave us ! I’m not going to do a blog post trying to summarize everything because there is just so much to say.I’m going to try to share my point of view on what I’ve seen here.

Our new platform

The original picture shown during the keynote to introduce the new platform was this one:

There has been a lot of confusion about that because of having XAML with C# in the Metro Style Apps without any reference to the CLR… Doug Steven did a pretty great job (blog post is here) by discussing with key people from the engineering team of Microsoft and creates this new more accurate picture:

Here is a quick summary:

  • there is only one CLR
  • .Net framework 4.5 is used in both Metro apps and Classic apps
  • it’s the same MSIL for Metro apps and Classic apps
  • in the Metro platform, we have a subset of the .Net framework (for example no OpenFileDialog…)

New opportunities

Before //BUILD we had already many choices to choose our development environment. we now have even more:

  • WPF and managed code for classic desktop apps
  • Silverlight in a web environment
  • Silverlight out of browser
  • WinRT + XAML for Metro apps
  • WinRT + HTML for Metro apps

I personally think that Silverlight in a web browser has not a great future. Microsoft just announced for example that the immersive version of IE will not run any plugins (so no Silverlight in the Metro UI) and we ‘ll know Microsoft is pushing HTML5 very strongly.

For classic desktop apps we have 2 options: WPF and Silverlight. Each of them has advantages and the choice we’ll have to do will depend on our constraints (deployment, business needs, connectivity…). I think there is room for the 2 platforms there.

For the Metro UI, you can choose between XAML and HTML. Microsoft told us they will keep a good feature parity between the 2 options. If you choose XAML and managed code you’ll be able to leverage a subset of the .Net framework.

I think another important aspect is that Metro will be available on Windows 8 only. Even though this new version of the OS might have a fast deployment rate (thanks to the slates), in many companies I don’t think it will be that fast.This, plus the fact that some LOB apps will not benefit the Metro UI leaves a lot of work to do in the desktop applications world (where we have both WPF and SL)… For WPF, we now have a new version coming in .Net 4.5. You can check out the new stuff here in the documentation.

In my next blog post I’m going to try to go deeper in the new WinRT/XAML world and see how it looks like for us, WPF and Silverlight developers.