I must preface this post. There are more than 10 concurrent sessions in each slot, and obviously I’ve only seen one in each session. I also picked my sessions based on my perspective as a .NET / C# developer.
I’m actually very pleased with what I saw today about the WinRT APIs and the C# language.
Let’s start at the WinRT layer. Currently, the base Windows API is Win32. That API dates back to 1995. In fact, the Win32 API was based on and consistent with the Win 16 API, which means its design is even older. Its design dates back to a day when C++ (and other object oriented languages) were not very popular. It also dates back to a time when the concept of having a computer attached to the internet whenever it was on was unthinkable. It’s also an API that has grown considerably over the last decade and a half. New features and capabilities have been added with each successive release of Windows.
The Windows Runtime (WinRT) represents a redesign of the entire API surface for windows. Throughout the day, I heard three phrases repeated from presenters discussing this new API:
I believe the WinRT team redesigned the Windows API from first principles, and created a modern API for the Windows system. It should be easier to use, and simpler for developers to understand.
That means languages such as C# and VB.NET will immediately have access in their own natural syntax to any new features available in the OS.
In addition, the next version of the C# compiler (and the VB.NET compiler) can produce WinRT components. The projection infrastructure is already there, and if you desire, you can expose your current class libraries (almost certainly after some work to make them conform to WinRT standards). C# is a first class language for WinRT development, just like C++.
Of course, nothing is free. If you want to participate in this new world, you must conform to the new WinRT standards, and possible leverage newer capabilities, and replace some code.
Some of the .NET APIs are changing for WinRT. I don’t have an exhaustive list, and I’m not sure there is one yet. Other APIs are not exposed via WinRT. (They are still available as .net APIs, just not as Metro / WinRT APIs.)
In the build we got, .NET apps will run in the classic Win7 desktop. It appears that all class libraries (that don’t rely on the Win32 APIs) will run in either environment. I’m not sure about that.
In Metro, the CLR runs on top of the WinRT layer. Just like today, where the CLR runs on top of the Win32 layer. There’s really not a lot of painful change here. Think about how thrilled you would be if you could write C# code that ran on other devices (like the iOS or droid platforms). if you think of WinRT that way, this makes sense: C# runs on both the win32 stack, and the new WInRT stack.
caveats: I’m still trying to figure this out myself, and I’m sure I’ve got some of this wrong. It represents my current understanding:
Are .NET applications legacy applications?
Well, sort of. The Metro UI is a different UI paradigm. If your using the current Win32 controls (which includes WPF controls), your application will look really dated in Metro. The only way to fix that is to re-implement the UI (your View classes in an MVVM design) using Metro controls. However, C# and majority of the .NET APIs are first class citizens in this new environment. The rest of your application should be fine.
caveat: WinRT has new network APIs and File System APIs. You may also have to change some logic at your persistence layer.
Is .NET Dead?
As a marketing brand, probably. However, C#, VB, F# and other managed languages are continuing just as strong as before.
It’s a good story for the platform. C# apps are as well supported as before. It’s just not as interesting of a story.
What about the future of the current Windows Desktop?
I don’t know. I’ve only had the build tablet for a day, and it’s a different experience. It’s pleasant for many tasks, but for others, I prefer a keyboard and the classic desktop. That may change as time goes on. And that will have a great bearing on how this evolves in the future.
My guess: “desktop” apps will run fullscreen in a private ‘virtual desktop’ in the future.
You should recognize that the Metro UI represents a rather large sea change in what makes a great application in Windows. If you ignore it, your applications will start looking dated.
However, this doesn’t mean you should rewrite your applications in WinRT. At least not yet. However, I would think carefully about what your application would look like in Metro. Is there a great Metro experience for your app? If so, start that migration.
Of course, some standard recommendations still apply: If you separate the layers of your application, it will be much easier to preserve large parts of your application as it moves to Metro. Regardless of your plans moving forward, that would be a good practice.
We do live in interesting times.
All of these projects are Open Source (using the Creative Commons license for content, and the MIT license for code). If you would like to contribute, visit our GitHub Repository. Or, if you have questions, comments, or ideas for improvement, please create an issue for us.