Last update: February 22nd, 2013
As new information about Windows 8 has become available, I have updated this post with new information about what is and isn’t dead in Windows 8. Here is an updated chart:
There is also an excellent developer matrix here.
What you consider dead depends on which part of Windows 8 you want to target. You have to decide for yourself… but generally speaking, you are statistically more likely to take the
Metro Windows Store app path. Metro Windows Store apps will be on all Windows 8 / WinRT devices (including Windows Phone, eventually) and will therefor be the most ubiquitous development target with the most reach within the Windows ecosystem.
The Desktop will also be on all Windows 8 devices – however, there are restrictions:
- You cannot target Desktop on ARM devices. On ARM devices, the Desktop exists primarily to attract enterprise adoption of Windows 8 tablets by offering a familiar and thus low-training-cost Office & IE experience on Windows 8. Despite the specific enterprise niche, a politically-charged issue of “consumer choice” has been cited by Mozilla, whos browser product (just like Visual Studio and the multitude of games published by Microsoft) will not be available to ARM Desktops users. The Desktop development restriction is indeed a comprehensive one, but applies only to ARM devices. Desktop development on x86/64 devices remains an available development target.
- Beginning with Visual Studio 2011, the free Express editions of Visual Studio will only allow
MetroWindows Store apps when it comes to Windows 8 development. If you want to create an x86/64 Desktop app utilizing new features in .NET 4.5, doing so will require a full / paid version of Visual Studio.
For most developers,
Metro Windows Store app tooling will be more accessible, and the platform itself will offer the biggest reach. It will therefor make the most sense for most developers to gauge platform viability from the context of Metro Windows Store apps. From that perspective, the short answer is that WPF and Silverlight have been simultaneously merged and replaced by “XAML”, which runs on a subset of .NET 4.5 over WinRT (the so-called .NET for Windows Store). XAML looks & feels similar to WPF/Silverlight and allows the use of C# & VB.NET languages, just be aware XAML utilizes a different runtime from that of WPF and/or Silverlight so code is not 100% portable between them.
XNA devs have it a little worse off; they lose their comfortable managed gaming framework using C#, and must reboot into C++ and unmanaged DirectX. Consequently, frameworks that wrap DX (SharpDX, Unity3D, MonoGame, et al) have been receiving more attention lately from .NET developers seeking alternatives to XNA.
The technologies closest to “dead” are Silverlight and XNA, as their platform reach shrinks to a functional EOL on x86 desktops, and Windows Phone 7/8. Silveright and XNA have lost prominent managers / developers / evangelists, many within the past few months (Scott Guthrie, John Papa, Jessie Liberty, Shawn Hargreaves, Michael Klucher, etc). Silverlight and XNA will continue to work on x86-64 Desktops but the writing on the wall indicates that updates to these products will be unlikely.
XNA update: As of August 20th, 2012, an MSFT employee has reported that it will be possible to create XNA projects that specifically target Windows Phone 8. Such an application would not be compatible with Windows Phone 7.x. However, Microsoft continues to assert that there is still no managed DirectX solution for
Metro Windows Store app on Windows 8. It is therefor likely that support for XNA on Windows Phone 8 relates to backward-compatibility with the Windows Phone 7.x marketplace, which grants Windows Phone 8 the special ability to run Silverlight and XNA applications. This special ability is apparently not planned for other Windows 8 Metro Windows Store app-only devices like the Surface.
XNA update #2: As of February 2013, it has been revealed that Microsoft is phasing out XNA.
The fate of WPF is ambiguous, because there actually are updates to WPF in the full-fledged desktop version of .NET 4.5. Future updates will probably hinge upon how we all use Windows 8 in the real world – whether we cling to Desktop (and perpetuate a need for WPF’s continued evolution) or embrace
Metro Windows Store apps completely (in which case WPF EOL – and perhaps Desktop .NET on the whole – would be a reasonable decision).
Here is the original post from September 15, 2011.
The difference between Metro and Desktop
“Desktop” is a way to describe the Windows programming model as we know it on Windows 7, Vista, etc. For .NET developers this means, essentially, programming in Silverlight and .NET. Unlike DirectX and XNA Game Studio, Silverlight & .NET are mainly used to create productivity applications.
In Windows 8 on the PC, this programming model hasn’t gone anywhere, it just has a new name – “Desktop”.
“Metro” is a new Windows environment geared towards a casual, consumer-focused experience. Metro has been specifically designed to compete with the consumer-centric experience you find on the iPad:
On the PC, these two experiences co-exist side by side. At first, Metro appears to be a new “feature” of Windows 8. At first you think “this is just a fancy Start screen”, or, “this is just bolted on top of Windows 7″. However the closer you look at what is happening with Metro, the more you begin to realize it is tantamount to an entirely separate OS.
Windows 8 represents a new shift for Microsoft – they are no longer focusing only on productivity. Windows now has 2 sides; the side we’ve known for years – the productivity side – now called “Desktop”, and a casual, consumer side called “Metro”.
For a .NET developer, difference is big. You can now write a casual, consumer app – like Solitaire – using the new programming tools for Metro. You, the developer, will continue to use the productivity Desktop, running Visual Studio to develop your Solitaire app. When you are finished, your grandma can launch the Solitaire app from a live tile on the casual Metro side of Windows 8. A Windows 8 PC is split between dev/prosumer & pure consumer.
Metro: more than just a “style”
Metro is a new way of thinking for Windows. It is an entirely new model for building casual, consumer-oriented Windows applications. This is new – even newer than Silverlight – because a consumer-oriented Windows OS has never existed before. If you are a developer questioning the “death” of things like Silverlight and .NET in Windows 8, you are probably hearing these rumors from people asserting that the casual, consumer-centric Metro is “replacing” the professional, producitivity-based Desktop side, but this is not the case.
Metro is a new, separate stack of components that include:
WinRT is the new Windows 8 API . Before, the WinAPI was traditionally a cryptic hassle to use from .NET. MS recognized this and re-invented the WinAPI for Windows 8. For .NET developers, WinRT dramatically improves the Windows programming experience by exposing methods that look and feel like a .NET assemblies. Because working directly with Windows is made so much easier this way, there is less reliance on a “framework” – it starts to make more sense to simply ask Windows to do things directly.
You can still C#, and there is still CLR between you and WinRT, so you still get to use LINQ & lambda expressions & managed memory & familiar syntax. At the same time, you are now in closer communication with the operating system and relying less on a framework. More “Windows.” namespaces, fewer “System.” namespaces. Great vid about it here.
This is the CLR between you and WinRT. MS simply calls this “C# and VB”; I like to call it Metro.NET [Note: the latest official name for this version of the .NET framework is ".NET for Windows Store"].
Explaining Metro.NET to a .NET dev is a lot like like explaining Silverlight to a .NET dev. It looks like .NET, it feels like .NET, but it’s not literally the same .NET we know & love. It’s a new edition of .NET made specifically to “wrap” WinRT; to program against Windows through managed code.
MS tends to keep this part of the puzzle somewhat transparent in the Build keynote(s), referring to it simply as “C# & VB”.
If you’re a .NET developer, Metro UIs are built with XAML, and so will be very similar (if not identical) to Silverlight and/or WPF in that regard. The only reason this is important to point out is because the entire Metro stack is generally now referred to as “XAML” in order to differentiate it from Silverlight or WPF. It is differentiated because it is an entirely separate programming stack for this new, casual, consumer-focused side of Windows.
Where do LOB / productivity apps fit into Metro?
The same place that LOB / productivity apps fit into the iPad, or an Android phone… they don’t. It’s kind of the wrong venue.
Metro is Microsoft’s consumer-centric platform. It’s Microsoft’s iPad. If you’re building a productivity app for the enterprise, you probably do not want to use the casual, consumer-focused Metro platform. It is therefor extremely important to continue viewing “Desktop” – .NET & Silverlight – as viable solutions. If you try to force productivity apps onto Metro, you will confused and frustrated very quickly. For instance, you can’t use modal dialog / multiple windows in Metro. You will look at Metro and be flabbergasted that you’re expected to use it to do “serious database work”, or create billing software. The answer is: Don’t do it! Use Desktop. Metro does not replace Desktop.
Let me repeat that: Metro is not replacing the playing field. In short, Apple split the playing field in half with the iPad, and it’s been playing over there, all by itself, with no real competition. Metro seeks to invade that half of the field. You have to make sure you’re targeting the right field now that there are 2.
You should expect to see this happen in the future – very lightweight tablets running only Metro as an OS:
Would you even want your LOB app running in this casual, consumer-focused environment?
Think of Metro as a dedicated, stand-alone platform for a casual, consumer-focused experience. It is not being designed for high-volume productivity. It is being designed, in short, to compete with the iPad. If your app is not a good fit for iPad, then it’s probably not a good fit for Metro, either.
None of this means productivity is dead; it means “There is a new casual OS – make sure you know which one is appropriate for your app”. What is changed, and what is new, is that consumer-focused apps (think: Angry Birds, Twitter, Web Browser) no longer must “shoe-horn” themselves into the productivity Desktop experience. These types of apps are now free to stretch their legs in a casual, consumer-focused environment build just for them. It is the proverbial “Angry Birds” developer that must change and learn this new Metro stuff. LOB/productivity apps do not need to move from the Desktop.
What about XNA?
The data we have conflicts with common sense. The data we have is that XNA does work on the Desktop and here’s proof. However, it’s not supported in Win8 preview’s Metro space.
Common sense tells us that XNA is very much a consumer-oriented platform. And Metro is a consumer-oriented experience. So… you do the math. In the meantime, if you’re dead set on doing “Metro XNA”, you have to fall back to unmanaged C++ & DirectX for rendering.
How can Silverlight, WPF, XNA not be dead?
It’s strong on Windows Phone. It may also serve as an effective band-aid to port Metro apps to Windows 7 and below. Apart from that, Silverlight’s not the most useful platform for most other cases.
So it’s not really dead; but I’m not an echo chamber for MS, either. IMO, the focus on Silverlight has, and will continue to slow down as the number of useful scenarios for it dwindles. It’s primarily alive and well on Windows Phone, will probably be used to back-port Metro to previous versions of Windows, and for what it’s worth, still installed on a good deal of browsers. IMO, that describes 99% of Silverlight’s role in the grand scheme of things, which isn’t that much. But it does have a use, and is therefor not entirely dead.
Not dead! What else are you going to use for productivity client apps – WinForms? Thing is, productivity client apps are themselves becoming sort of niche lately. But if you actually do need to make a solid productivity Windows client app in the real world, WPF is still the premier choice.
Not dead! XboX, Windows Phone, Windows Desktop. And I would be very shocked if XNA is not eventually integrated into Metro.NET at some point. The name might change – it might not be called “XNA” after all’s said and done – but the essence of managed DX should by all accounts live on through Metro.
Isn’t “Desktop” just another word for “Legacy”?
No. “Desktop” is just another word for “productivity”. And it’s an apt term; productivity apps prefer the traditional Windows Desktop environment just as casual consumer apps are better in Metro. Truly, we are looking at having a single OS that offers the best of both worlds on the PC – and that is what is cool about Windows 8.
The iPad suggested to the world that the PC market wanted a division between productivity- & consumer-centric experiences & devices. And Apple was right. Now everyone (particularly MS, who’s generally been productivity-centric) is playing catch-up with the concept of a “non-productivity experience” and the market’s awash in consumer-centricity.
So, consumer-centric ideology is the hot flavor of the
month decade right now. That does not mean productivity is “legacy” or “dead” though. IMO, they are not mutually exclusive concepts, and Silverlight & .NET are no more “dead” now than they were a year ago.
Hope that helps cheer up some the depressing keywords finding my blog.