So what does Windows 8 mean for .NET developers?

Last updated on September 22nd

Unfortunately, the Microsoft Build conference conflicted with our company's 5-year anniversary and the associated sailing trip in Greece.

Fortunately, the blogosphere and twitter-space provided plenty of opportunities for trying to grasp what the stuff Sinofsky and his team have been sharing in Anaheim means for us developers. I tried to read as much as is available right now , and this is my interpretation of that news. But first, consider this improved diagram (created by Doug Seven) in his interpretation of the Windows 8 story.

Metro apps

• Are supposed to exist side-by-side with desktop apps (at least, for the next few Windows versions).
• Run in a kind of sandbox and don't have access to desktop apps
• Are suspended within 5 seconds after the user has switched to another app. This should increase battery life and keep the system responsive.
• Cannot use overlapping dialog boxes
• Can only be distributed through the upcoming Microsoft app store and require verification and signing before any app is allowed. I don’t know whether there are any other mechanism for distribution.
• Can implement specific APIs for easy exchange of files and other data streams (e.g. you don't have to download a file to a disk first to use it in another app)
• Can be build using three sets of technologies, all ran against the new WinRT API. Consequently, Metro apps can be build regardless in what technology you have been investing:
  • C/C++ with XAML
  • C#/VB with XAML and .NET 4.5/CLR
  • Javascript with HTML5/CSS
• Microsoft introduced a specialized version of Expression Blend for HTML that you can use for building HTML/CSS/JavaScript apps.
• Microsoft apparently didn't mention JQuery, but it seems to work after all.
• The JavaScript apps will run using the Internet Explorer 10 engine and doesn't allow any plug-ins to run. This has nothing to do with IE10 as you would use as a desktop app. There, all plug-ins still work, including Silverlight, Adobe and other traditional plug-ins.

WinRT

• The following diagram extracted from the Lap Around the Windows Runtime session by Martyn Lovell provides a more in-depth view of the runtime.
  
• WinRT is a fully object-oriented API next to Win32 that talks directly to the Windows Kernel. It is based on a modern version of COM, but that fact is completely hidden away.
• WinRT is created for the fast fluid experience required for Metro apps, so any operation that might take longer than 50ms to complete is only available through an asynchronous model
• The WinRT objects are exposed using language projections at compile-time (C++ and .NET) and/or run-time (JavaScript and .NET)
• WinRT provides language independent primitive types for integers, enums, (immutable) strings, arrays and interfaces. They are projected to the corresponding language-specific types.
• WinRT uses a metadata system similar to .NET Reflection based on COM’s IUnknown and a new IInspectable interface.
• Apps cannot expose its objects to another app, other than through the earlier mentioned communication contracts.
• If you develop in C#/VB, then you'll be running against the full .NET framework, but the API is filtered to what WinRT can provide. It works similarly as the .NET Framework Client Profile works. You could still use Reflection to access the hidden parts, but such apps will not be accepted by the app store.
• You can use C++ and .NET to build WinRT components and then use them from all three development models (including Javascript). Doing this, does impose some limitations to your classes.
• The UI runs on a single non-reentrant thread, but an app can still use the thread pool.
• Existing Silverlight apps only require a few minor changes to some namespaces and any networking code to be able to run as Metro apps
• Already many open-source Silverlight libraries are working on supporting WinRT. Caliburn Micro for instance, already supports some parts of WinRT.
• Make sure you read the excellent in-depth analysis of WinRT by Miguel de Icaza and the threats/opportunities analysis by Steven Smith.

This also means that Metro apps have nothing to do with Silverlight, WPF or any other part of .NET for full-blown desktop apps. In fact, Windows 8 ships with the .NET Framework 4.5 which includes a shipload of new improvements, even to WPF. Everything discussed around WinRT and Metro is about building specialized apps specifically targeted to Windows 8. As far as I'm concerned, any posts or discussions talking about the death of the .NET framework or Silverlight (shame on you InfoQ!) don’t (want to) get the whole picture.