Question

In my attempt to understand reference assemblies and how the CLR is handling these, I am a bit confused of how many different .NET CLR’s that actually are in play.

Looking at the .NET Metro profile, where the API is projected by winmd files and later handled in .NET by reference assemblies, what version/kind of the CLR is taking care of this ?

It seems it’s the same sort of mechanism that takes place for the Silverlight profile and Windows Phone profile, so the same CLR is loaded for each of these but only exposes the relevant API’s, depending on what you target.

Does it make sense ?

Answer 1

There’s one for every platform: desktop, mobile, phone, xbox, silverlight, micro. And sometime late this year there will be another one, ARM pad. But that’s not what matters, your program builds against the reference assemblies, not the CLR. All calls your program makes are framework method calls, you never call a CLR function directly.

So there are profiles, collections of reference assemblies that are stored in c:\program files\reference assemblies. They roughly fall along platform boundaries, but with additional variations. Like a desktop app can target full, client or metro profiles. The key feature in a reference assembly that enables WinRT targeting is that it can redirect a type. That magic is implemented by the [TypeForwardedTo] attribute.

So when you target the .NET api for Metro profile, your reference assemblies come from the Framework\.NETCore sub-directory and you’ll have a reference to the mscorlib.dll reference assembly that redirects all types to another set of assemblies that implements the WinRT projection. Core ones are System.Runtime.dll and System.Runtime.WindowsRuntime.dll and others. Same mechanism that enables the Portable Class Library feature. More details here.