For the past few months, there has been a somewhat heated debate over the future of .NET on the new Windows 8 platform. Folks were concerned about the possibility of having to abandon their 10+ years of investment and being forced to move towards other things like C++ or JavaScript. Don’t get me wrong, both C++ and JavaScript are amazing technologies, but for a hardcore .NET developer, they represent alien worlds.
With the new release of Windows 8, the obvious was officially confirmed. Not only .NET is here to stay, but it gets even more important. On one hand, it gets tons of new features for server-side development. On the other hand, it remains a first class citizen on the client too. I’ll leave the server side for a future post and I’m going to focus in the reminder of this post on the client story.
The first thing you need to understand is that Windows 8 comes with the full version of .NET 4.5. Here’s the proof for that:
The version of clr.dll (located in C:\Windows\Microsoft.NET\Framework64\v4.0.30319) indicates 4.0.30319.17020 (as opposed to the latest .NET 4.0 version which is 4.0.30319.225 if my memory serves me well).
The second important thing to understand is the way in which apps are run on Windows 8. There are basically two major categories of apps: desktop apps and Metro apps. The following picture shows the high level architecture of this approach:
A desktop app is the type of app we’re all used to from previous versions of the OS. When it comes to .NET, this is a full .NET client application, with all the stuff in it. Obviously, old apps will run without a problem. Whether they are WPF apps (like Visual Studio for example 
), Silverlight, or any other type, they will just run. I want to be crystal clear on this: DESKTOP APPS ARE NOT SECOND CLASS CITIZENS IN WINDOWS 8. They continue to represent an extremely important part of the platform.
A Metro app is they new type of application that uses the new interface style introduced by Windows 8. In a nutshell, this type of interface is based on the Metro UI concepts, and it’s optimized to be used in both touch and keyboard-mouse scenarios. The important thing to understand here is that these apps are run in a protected environment. Which makes a lot of sense since this is the “tablet” world where you’re interested in providing an environment for secure and safe applications that can be downloaded and installed in a very easy way from an app store. The protected environment is provided by an AppContainer (a new concept introduced by Windows 8). In this protected environment, the app will be allowed to do only certain things. Simply put, it’s a locked down medium where you have to play by the rules.
As you can see in the picture above, among the types of Metro apps you have the C#/VB apps (aka the .NET apps). Now this is where things are becoming interesting. You might have noticed that they run on top of something called the WinRT (Windows RunTime). WinRT is basically a set of native APIs, highly optimized, that run on top of the OS kernel itself. Understanding the role of WinRT is key to understanding this whole new model of app development.
WinRT inherits a lot from .NET. To name just a few things:
- Metadata (Because native code does not support metadata embedded into it, the metadata is stored in separate files with an WINMD extension. These files are located in C:\Windows\System32\WinMetadata. The cool thing is that the format used is the .NET format – with some minor additions. This means you can even ILDASM these files. Although it’s a .NET format, the metadata approach in WinRT is unversal, meaning that it is available across all languages)
- .NET style namespaces
- .NET compatible base types
- Native support for XAML
So, as you can see, .NET had a fundamental influence on WinRT. BUT WINRT IS NOT .NET. It’s a set of native APIs available for all Metro languages (C#,VB, C++, JavaScript). To clarify even more:
- WinRT is the API used for Metro apps – it is not available for desktop apps
- Win 32 is the API used for desktop apps – it is not available for Metro apps
But WinRT also introduces some fundamental new approaches:
- Asynchronous calls are used exclusively in lots of places (as opposed to previous approaches where the developer had a choice between synchronous and asynchronous – this just emphasizes the laser focus on performance in Windows 8)
- No message loop (believe it or not, it’s not there )
- No GDI stuff, all graphics goes via Direct X (it’s not yet very clear what is the current position of XNA in this, we’ll have to wait and see)
Now that we are clear about the context, let’s get into the details of Metro apps developed in .NET. When you use the C# or VB Metro app template, you are basically developing against a .NET framework profile named .NET Framework Core 4.5. This means that there are only certain things from the full version of .NET 4.5 that you can use in your app (much like we had in previous versions with the Client Profile). In addition, there is only one AppDomain (the Default). But don’t worry, all the cool things are there: generics, LINQ, and so on. The new thing is that you can also use WinRT namespaces as first class citizens in your .NET app. This is possible because of the metadata model I described above.
What you get when you compile you code is plain old MSIL which runs inside the .NET CLR. The interesting part here is that when your code gets JIT-ed or NGEN-ed, based on the WinRT metadata that you refer to, the WinRT metadata references are transformed into v-table calls into the native libraries.
In a nutshell this is the story with C#/VB Metro apps:
- They run in the CLR as all .NET apps do
- You get the power of .NET 4.5 (except for constrains imposed by the Core profile)
- You consume transparently WinRT libraries (via the new metadata model introduced by WinRT)
- Your execution environment is further constrained by the OS (via the AppContainer)
- Your UI is based on XAML which has native support in Windows 8 Metro apps
Well that’s about it. Obviously, all info in this post is based on information available right now, which might change. It could also be that I misinterpreted some of the info and had drawn some inaccurate conclusions. But the big picture is clear beyond any doubt: .NET is here to stay in Windows 8. You can use it either for desktop apps which benefit from the full power of the OS and the .NET Framework, or you can use it to develop Metro apps which benefit from the CLR and the native, high performance, layer of WinRT.
To paraphrase a classic: “the rumors of .NET’s death are greatly exaggerated”. Not only it’s present in Windows 8, but it’s even taken to a whole new level, and some of it’s key concepts have been broadened and made available throughout the entire OS, as native implementations.
Stay tuned for more great stuff coming from //BUILD.
Subscribe