I am spending this week at the Build conference where Microsoft just released their preview of Windows 8. After the initial message of "everything is okay, you can still use what you know", we had some more in-depth sessions yesterday. And here is, at a high-level, what they have done. They have taken COM and made it a "first class" citizen in .NET. Their new WinRT layer is actually COM. But COM is all about interfaces, and .NET is all about objects. So what they have created is metadata for all the winRT interfaces and mapped those into object oriented equivalents that are exposed in .NET. Thus you no longer need to deal with COM interop when talking to winRT (their framework takes care of it for you).
The other messages is that everything has to be async if it takes more than 50 ms to access.
Here is the rub. Last night I set out to build a new METRO style app to see what it was like. I set my goal low: read some XML in from a file and display it in a grid. Been there, done that, shouldn't be that hard, right? Here are some of the challenges:
The first challenge is getting the right to access a file. I was storing the file in the document library, so I figured there was probably some kind of privilege setting required in the new application manifest to allow access. And there was :). But after changing all that good stuff I still ended up with a blank screen. Huh. They mentioned that if you didn't have the right privileges set, you would get some kind of an error. I am yet to see that, the UI was just blank and no error other than in your debugger. Anyways, after more digging into one of their sample apps, I figured out you also need to specify in the application manifest the specific file extensions that your application will be associated with. If you don't, you will get an 'access denied' error.
Second challenge was actually reading the data. Obviously, since it could be more than 50 milliseconds :), that is an async call. So you go into their new 'Windows' namespaces and find the classes to read a file async. Not that bad. However, here is the rub: all of the winRT functionality is mapped into interfaces. Remember that this is actually COM that is interface oriented? So I like using the classes in the System.Xml.Linq namespace for reading a stream into an xml document. Oooppsss ... you are not getting a stream back from the async file read, you are getting one of the WinRT specific interfaces back. So after some digging I find this new 'Windows' based xml document class that does allow you to process the interface that winRT returns.
Even more fun, winRT doesn't allow you to just inject regular .NET classes, it specificly wants winRT classes in many scenario's.
If this was confusing: sorry, it is also somewhat confusing to me :). Right now it feels like you have to two frameworks awkwardly rolled into one: the .NET framework and the WinRT .NET framework. And they both for example have a way of dealing with Xml documents. So you are choice is to put all these conversions together between winRT and the 'desktop' .NET classes you are familiar with, or you live in a divided house where there is yet another way of working with an XML document. Developers are require to once more split their personality. You already had a WinForms, ASP.NET, WPF and SL personality, now you can start to raise your winRT personality.