DCSIMG
Metro .NET Framework Profile (“Windows Tailored”) - All Your Base Are Belong To Us

All Your Base Are Belong To Us

Mostly .NET internals and other kinds of gory details

Metro .NET Framework Profile (“Windows Tailored”)

The amount of confusion generated by the first two keynotes at BUILD was immense. The blogosphere and Twitter were brimming with bold rumors of the “.NET is dead” kin. I even heard someone discuss seriously the possibility that C# Metro apps will be compiled directly to native WinRT bindings, bypassing IL and JIT altogether, so that clr.dll won’t even be loaded.

Even though I disproved these rumors two days ago, it was still great to hear Krzysztof Cwalina explain in detail how .NET remains a fully-featured framework for developing Metro applications in C# and VB.NET. As you may have heard or noticed, not every .NET API is available to Metro applications – and the subset of APIs available to Metro applications is called the “Windows Tailored” or Metro profile.

Even before Metro, .NET had numerous target profiles – the Silverlight profile, the Windows Phone 7 profile, the .NET Client profile, and of course the full profile. The way profiles are implemented is a compiler trick. Visual Studio ships with a bunch of reference assemblies that you can find (on a default install) under C:\Program Files\Reference Assemblies\Microsoft\Framework. These assemblies contain only metadata and no executable code – indeed, they are not necessary at runtime because when your application runs, .NET assemblies are loaded from the GAC. To project only a part of the available APIs from the implementation assembly, the reference assembly simply omits whatever namespace, types, or methods that are not included in the profile.

Clearly, there are ways to circumvent this mechanism, such as binding directly to the GAC assemblies instead of using the Visual Studio-provided references. Another option is to use reflection at runtime. These are valid possibilities – with the minor setback that your application will not pass Windows Store certification if you use unsupported APIs. (This idea, of course, is not new, and has been exercised by Apple in iOS apps for quite some time.)

The same idea exactly is used for the Metro profile. It executes at runtime using the same assemblies as the full desktop CLR, but only a portion of it is available to Metro applications. What kinds of APIs were removed?

  1. Irrelevant APIs were removed – think ASP.NET, WPF, Console access.
  2. Obsolete and dangerous APIs were removed.
  3. Duplicate APIs were removed.
  4. Windows API wrappers were removed, in favor of the WinRT types.
  5. Badly designed APIs were removed.

Specifically, the following APIs that are not part of the Metro profile you are most likely to miss:

  1. System.Data – removed entirely. There is an OData component, but no LINQ to SQL or anything of that sort.
  2. Remoting – removed entirely.
  3. AppDomains – removed entirely. There is only one AppDomain in each Metro application process.
  4. Reflection.Emit – removed entirely.
  5. Private reflection – you cannot invoke private methods, internal methods on another assembly, access private members and so on. (Frankly, I am not so upset about this change because I’ve grown sick of “clever” solutions using some undocumented private member which breaks in a year or two.)
  6. System.Thread – must use Task.Run instead for all threading purposes. (Creating a new thread is roughly equivalent to creating a task with  TaskCreationOptions.LongRunning.)

What kinds of APIs are included in the profile, or will require porting to use the profile?

  1. HTTP client stack is included.
  2. XML (through XML LINQ mostly) is included.
  3. Serialization is included (DCS).
  4. MEF is included.
  5. WCF client stack is included.

The end result is a very slim subset of the .NET framework, with only 15 implementation assemblies and ~1000 types spanning 60 namespaces. (This does not include the WinRT APIs and the Windows.UI.Xaml stack.)

Obviously, one of the reasons the resulting framework is so slim is that so much is provided by WinRT. Life has not just become easier – quite the opposite, because you have to go and learn WinRT. However, the interop story with WinRT is incredible – or rather, completely transparent – due to the brilliant type mappings from the WinRT type system to managed languages. (Quite possibly the most incredible automatic language projection is the way WinRT operations are projected to .NET Tasks and JavaScript promises.)

Posted: Sep 17 2011, 03:19 AM by Sasha Goldshtein | with 12 comment(s)
תגים:, , , ,

Comments

Lior Tal said:

Do you know if it's possible to develop metro apps on win7, without using the vhd file of Win8?

# September 17, 2011 5:00 PM

Svick said:

Except WinRT asynchronous operations are not projected to Tasks. But they look like something that implements the Awaitable pattern (through an extension method), so you can use await on it.

# September 17, 2011 8:53 PM

John Hartland said:

Are the 6 listed APIs above the major ones that are missing?  If that is the case then I am not sure why you mention that the end result is a "very slim" subset of the framework?

Thanks,

JH

# September 19, 2011 12:28 PM

John said:

This is great information.

Where can we find a specific list of the 60 namespaces? Or information more specific than you listed here about what of 4.5 is available in Metro apps?

Thanks!

# September 19, 2011 11:13 PM

Sasha Goldshtein said:

@Lior Tal: No, I don't know of a way to do that.

@Svick: Thanks for the correction.

@John Hartland: These are just the things "you are going to miss the most". But plenty of other things aren't there either. WCF (server-side), WF, EF, WPF, ...

@John: Why not open Reflector and take a look? :-)

# October 11, 2011 8:30 AM

Pinoy Classifieds said:

While .NET on top of WinRT all sounds good, one can't help but be suspicious that .NET will eventually be left by the wayside.

I am reminded of how Managed DirectX was just left to flounder when the powers-that-be at Microsoft got entranced with XNA.

The history of Microsoft is littered with the corpses of dead APIs and my bet is that .NET will not last for more than 2 generations and will join the ranks of MFC, ATL, Windows Forms, WPF and Silverlight.

Meanwhile, the Apple ecosystem - despite its considerably more primitive Objective-C environment - is looking more and more appealing by the day.

# October 16, 2011 8:21 PM

Webmechs Editor said:

webmechs.com/.../winrt-and-cocoa-api-evolution-ms-vs-apple

Unlike for Microsoft, OS X developers are not being asked to forget what they know about desktop Cocoa development.  Rather they are being given the impression that as time goes by, more and more of their skills on both iOS and OS X can be shared across both platforms.

Even if this were merely an impression and if the truth is that a lot of relearning was still needed in the transition from desktop Cocoa to Cocoa Touch,  certainly Cocoa developers do not have the same angsty feeling that Microsoft developers have felt recently.

While nothing out there is anywhere near as advanced as the CLR, and this remains the one trump card of Microsoft, Microsoft seems to be at a loss with how to evolve their APIs going forward in a way that doesn't piss off developers.  

As for me, IT'S THE CLR I LOVE and I really really want to see Apple officially adopt Mono in order to make Cocoa development less primitive.

# October 23, 2011 7:16 PM

Sasha Goldshtein said:

@WebMechs: I don't share your feeling. On the Microsoft platform I can use the same language (C#) - with no strange quirks or limitations - across the desktop, tablet, and phone. I can use a subset of the always familiar .NET Framework across the desktop, tablet, and phone. I can use the same programming paradigms (EAP, Async), the same design patterns (ObservableZZZ, Data Binding), the same design language (XAML) - across the desktop, tablet, and phone.

# October 24, 2011 8:32 AM

The Admiral said:

This is bloody ironic. I CAN get into the Apple App Store with System.Data (by using MonoTouch.)

But I CAN'T get into the Windows app store with it? The decision to ditch System.Data is a foolish spiting of your own developer base. I will NOT develop for this new platform.

# December 16, 2011 3:55 PM

batDan said:

Its surely not the right place to discuss this, but just to express another view: Managed languages are a nonsense on low power devices and Microsoft realised this with moving from .NET and C# to WinRT and even unmanaged C/C++ code. Apple realised this long time ago, that's why they developped a superset to C with Objective-C which is far more enhanced as ppl here realise. It was perfectly dynamic from the beginning in opposite to your hyped CLR and now it makes even the ressoure wasting garbage collection obsolete with Automatic Reference Counting. Of course it's quite different and needs some learning, but once you got it, you'll realise the elegance and efficiency of it...

# June 7, 2012 4:07 PM

lolo said:

Pls, explain how a plug-in based app like Photoshop, Maya or 3dsmax can tun rin WinRT without loading dynamically plugins ... How can a 3rd party developer program a plugin if the .EXE can use only referenced assemblies.... That's a MAJOR flaw in WinRT design 8(

# November 4, 2012 10:58 PM

Sasha Goldshtein said:

@lolo: plugin-based apps should not be Windows Store (Metro) apps. There would be no way to ship the plugins through the Windows Store anyway. I am seeing a common trend here: people think that EVERY app should now go the "Metro" route. That's not necessarily the case.

# December 24, 2012 7:13 AM
Leave a Comment

(required) 

(required) 

(optional)

(required) 


Enter the numbers above: