In the previous post, I’ve explained how to use WinRT APIs from a .NET Desktop application to list the installed Metro App packages. This post is dedicated to the other side of the story: what part of the Microsoft .NET Base Class Library is usable from a C# Metro App.
Since “.NET for Metro style apps” sounds quite abstract, open up its properties:
The exact name of the assembly is not provided but only the folder where it should be found. I’m using the “it” word but I should use “they” instead. Unlike Dekstop .NET application where each exact required assembly file is listed in the References of the project, Metro .NET App projects simply refers to .NET as a whole.
If you need to figure out from which exact assembly the BCL types definition comes from, simply “Go To Definition” on a type in C# source code. For example, type
StringBuilder and right-click it to select Go To Definition (or type F12 directly). Visual Studio then opens up a “view” of the type generated from its metadata:
At the top of the file, you get the full path of the .dll containing the metadata for
This folder contains many .dll files that contain just the types definition metadata without any IL code: the equivalent of .winmd files but for the Base Class Library! Note that the comments provided by Visual Studio are extracted from the sibling .xml files in the same folder.
A different packaging
When you have played with
StringBuilder and other BCL types for a long time, System.Runtime.dll does not sound familiar at all. If you create a dummy C# console application and go to definition of
StringBuilder, you end up with a different result:
A different folder for a different (but expected) assembly.
Is it a different story at runtime?
Let’s start the Console application and check which .dlls are loaded with Process Explorer from Sysinternals:
The same .dll files are loaded from the same folder. So there must be a kind of forward mechanism between the assemblies referenced at compile time and the real assemblies loaded at runtime.
In the same Metro App, let’s find the System.Runtime.dll that was referenced as containing the definition of the
StringBuilder type in Process Explorer. Here are its properties; including the full path from which it has been loaded:
If you load this .dll in your favorite .NET decompiler, you’ll find a lot of
System.Runtime.CompilerServices.TypeForwardedToAttribute defined at the assembly level like the following ILSpy screenshot:
StringBuilder type from which this post was started.
And you’ll get the following output:
System.Text.StringBuilder, mscorlib, Version=126.96.36.199, Culture=neutral, PublicKeyToken=b77a5c561934e089
Defined in System.Runtime.dll and implemented in the expected mscorlib.dll.
For more details about the Metro .NET profile, watch “A .NET developer’s view of Windows 8 App Development” by Krysztof Cwalina and read “Type Forwarding” by David Broman for type forwarding.
I hope this helps