WinRT or WinMD Components

The WinRT platform provides developers with a new way to build reusable software components. WinRT types packaged in a WinRT component, also called a WinMD component (WinRT components == WinMD components). In traditional .NET application development, you could create a dynamic-link library (DLL) as a managed class library and use it in one or more applications.

This option is still available in Visual Studio. However, you can change the output type of a library project from class library to WinRT component, and the output of such a project is a WinMD (Windows Meta Data) file.


Benefits of creating a WinMD / WinRT component.

Contrasting to the DLL files WinRT / WinMD components can be accessed by unmanaged languages like C++ and Javascript. This allows us to create a WinRT / WinMD component in a managed language (C# or Visual Basic) and use it across different Windows Store Apps (WSA) projects implemented in unmanaged languages.

But this flexibility comes with some restrictions.

  • All public classes in WinRT / WinMD component should be marked sealed.
  • public fields aren’t allowed.
  • public data members must be declared as properties
  • Data types should be WinRT / WinMD compatible
  • Creating a WinRT / WinMD component in C++ has some additional property attribute settings (activatable class and ect…)


Creating a WinRT / WinMD component in C#

This is a very simple example and straight forward create Windows Store Apps (WSA) class library. Mark the class public and sealed. Create a method to return a string value.


Go to Project Properties and change the output type from Class Library to Windows Runtime Component. 


Component Code image




Do the build.

Accessing the C# WinRT in Javascript

Create a WSA project in Javascript. Add the WinRT project reference to the Javascript project.

Create a Javascript method to call the WinRT method. VS intellisense would guide you.

Javascript Code.


Here you can notice that the GetDate() C# method is formatted to getDate() with Javascript naming convention.



Run the code. 🙂

Things to consider

When you create a WinRT / WinMD component it is specifically designed for the Windows Runtime. Windows Runtime supports different language executions. In the above Javascript project we have a WinRT component developed in C# executed in the Javascript app. This is very useful when you want to extend your existing LOBs. You can use your existing managed code with little modifications, this cuts down development cost.

And also some complex data processing codes are hard to be written in pure Javascript. You can implement those in C++ and use the component in your front facing Javascript WSA.


Accessing a WCF Service WinRT vs Silverlight

Hi, last few days I got some questions from few folks that they are confused on how to call a WCF service in WinRT (Windows 8). This confusion occurs mainly if you are Silverlight dev or Windows Phone 7.5 dev and you are used to the traditional async method and the CompletedEvent.

In Silverlight these two are very handy and generated by the VS.

Think a very simple WCF service that you get once you create a WCF Application project in the Visual Studio. It comes with a simple method GetData which accepts an int and returns a string.

In Silverlight, VS generates the async method and the async CompletedEvent method for us. so we can simply call the service and get the results like this.

private void Button_Click_1(object sender, RoutedEventArgs e) { Service1Client proxy = new Service1Client(); proxy.GetDataCompleted += (GetDataSender, Ev) => { TxtName.Text = Ev.Result; }; proxy.GetDataAsync(10); }


But in WinRT if you try do the same thing you soon will find that you are missing the CompletedEvent.

This is handled differently using the await and async keywords in C# 5.0 Read it in detail here.

Here’s the implementation detail of how you can call a WCF service in WinRT. Click to enlarge the image.


As you see the GetDataAsync method generated by the VS returns an awaitable Task. So it is simple than Silverlight, this what you have to do. Simple at its best.


But it is better to know how things work, but that is beyond the scope of this article and you can learn about it here

But what if you need to have a separate Application logic layer and wants to do some processing in the data returned by the service. (more often you need that)

Here’s a way to get the CompletedEvent architecture from Application logic and notifying it to the UI. I’m having my own even handler here.

Create a Class1 (your application logic layer)

class Class1 { public event EventHandler<MyWebServiceEventArgs> DataProcessed; public void HandleMethod(int value) { ProcessData(value); } private async void ProcessData(int value) { Service1Client proxy = new Service1Client(); string result = await proxy.GetDataAsync(value); DataProcessed(null,new MyWebServiceEventArgs(result)); } }

Create MyWebServiceEventArgs derived from EventArgs

public class MyWebServiceEventArgs : EventArgs { private string _myVar; public string MyProperty { get { return _myVar; } set { _myVar = value; } } public MyWebServiceEventArgs(string result) { _myVar = result; } }


In your UI layer do this

private void BtnClick_Click(object sender, RoutedEventArgs e) { Class1 c1 = new Class1(); c1.DataProcessed += c1_DataProcessed; c1.HandleMethod(10); } void c1_DataProcessed(object sender, MyWebServiceEventArgs e) { TxtName.Text = e.MyProperty; }


Open-mouthed smile I brought the Silverlight CompletedEvent model to WinRT.

But you can simply live a happy life with async and await keywords.

Microsoft’s confuzzled.

You might wonder what this confuzzled is. It’s a word I heard in a movie or in a TV series (don’t remember exactly where) as a combination of confused and puzzled. Hot smile Cool isn’t it ? But it perfectly suits the current situation of the Silverlight.

Silverlight is a good platform, no one can deny that. MS released it as a RIA plugin for the web. (initially to battle against Adobe Flash and Java FX) then Microsoft realized that HTML 5 is  great and started the promising of open web.

They started campaigning Silverlight is not meant for the web. At that time Mango was in a hype. So Silverlight got a safe shelter under the Mango tree. Island with a palm tree

Microsoft also announced the Lightswitch, which is based on Silverlight. (out of the browser feature).

Lightswitch has its own attention from some ISV’s and has been growing, but not much popular in a broader market. Though it is a pleasing platform to develop applications deployment of a Lightswitch app is little hard.

But now Silverlight got a very serious problem. It doesn’t know where to go and where to exactly fit in ? Because of the new boss – WinRT. Just kidding

We all know that Windows 8 apps are running on top of WinRT, and the Windows phone 8 is also a WinRT platform. No more  Silverlight in Windows phone.

Poor Silverlight it lost one of its major safe houses. Sick smile

So as of now Lightswitch is the only guaranteed place for Silverlight to rest in peace.

But you might wonder still we use the XAML in WinRT, so how come we loss the Silverlight. XAML is a powerful UI standard created for WPF and then ported to Silverlight and now being used in WinRT.

So still you can use the XAML skills you’ve got on layout, user interaction, data binding and so and so in the WinRT, but Silverlight is no longer there. That’s it.

So what about the existing WP7 (Mango) apps written in Silverlight, MS promised an automatic recompile of the apps in the marketplace to WinRT.

And since XAML is there, Silverlight devs no need to panic much, because they can still use the XAML and other features like Command model, Converter model and other patterns in WinRT. ( I think the dependency property is still there, not so sure)

Silverlight also has the promises of BI 2.0 but again in a very limited scope. In SQL Server 2012 the power view has some sort of a Silverlight touch.

So when calculating all the formulas, I think Silverlight 5 would be the last version. Party smile