So what does Windows 8 mean for .NET developers?

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.

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 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.

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.

Share on

Leave a Comment

You May Also Enjoy

It may be coincidence, but the two best tutorials I attended at Agile DevOps East both ran on the same day. The first one focused mostly on agile transformation, but briefly touched on the leadership topic. This one, let by Jennifer Bonine, took this further by focusing on being a better leader b...

For my annual conference trip, I decided to skip the always-great QCon conference for once and instead attend Agile DevOps East in Orlando, Florida. In addition to the typical conference schedule, I also registered for some of the half-day and full day tutorials. One of them, How to lead high-per...

Transient vs non-transient exceptions
If I have to name the single biggest flaw in adopting Event Sourcing, it must be our decision to rely on the synchronous dispatching pipeline of NEventStore. It is based on the idea that every event will be processed by all projectors in a synchronous manner....