@brian.shapiro I have no doubt that WinRT will eventually be available to desktop applications. Simply put, there is a fear in a lot of .NET developers minds that WinRT will replace WPF, which is simply not the case unless Metro is allowed to run on the desktop as well, which currently it cannot. WinRT makes specific assumptions, for example, that only one Metro application is open at a time, which would not be suitable in the desktop environment. Things can change, but since it is just rolling out as V1, not anytime soon.

@Charles Agreed. .NET is not suitable for OS development. Also, you have done PLENTY of .NET coverage... countless interviews with Anders, Bart De Smet, Erik Meijer and more... so I don't understand why it's an issue. .NET lives because of native and they should be greatful that C++ is evolving into a even more modern language.

There are too many new areas to cover right now.. C++ 11, Windows 8, Visual Studio 2012, .NET 4.5, C#5, VB, the list goes on. Poor Charles cannot cover them all at once! Unless maybe you have a few clones laying around.

I think there is just a "misunderstanding" of what WinRT is, and I think there is a lot of tension from .NET developers because they think Metro will replace WPF, and eventually deprecate .NET. I don't think either of those will be true, not just for compatibility reasons, the desktop is not going away.

I think the big push for mobile/tablets and bringing them together on the desktop in Windows 8 has a lot of people nervous as well. It's a very bold move and many don't know what to feel about it yet.

I think right now one thing Microsoft could do is help by, (and without promoting Metro/WinRT or doing anything related to advertising/marketing) is to better explain:

1) What is WinRT
2) Why does it currently only support Metro style apps if its a "successor" to Win32
3) Why does it only expose a subset of .NET API's and "govern" which ones can be used in WinRT apps (this makes developers feel limited, and they don't like that)
4) What is the future of WPF/Desktop (and including WinForms even, people still use it)

If I'm wrong on any of these points I apologize and would love clarification. These are based on my own understanding of WinRT/Metro and concerns I hear from other developers.

@SteveRichter It doesn't really matter how powerful hardware is. Managed code runs on native code. It doesn't exist without it, and no matter what type of device it is or how powerful the hardware, performance and reliability of the runtime/platform/operating system/device should always be the #1 priority.

In prior times, let's use Vista as an example, we were introduced with the DWM (Desktop Window Manager) which had cool new features like Aero glass. These features are baked into Win32 though, which means you have to P/Invoke to use them from .NET. The .NET team would have to write wrappers around the new Win32 features to make them available in .NET, but because of time constraints, that stuff never made it into .NET API's. WinRT removes this problem by allowing the Win32 API to be directly available through WinRT, so you can just directly access it. This means that in the future if X feature was introduced in the Win32 layer, it could just be exposed through WinRT, and .NET customers wouldn't have to wait for the .NET team to make a wrapper. This is possible because WinRT uses what they call language projections, which allow WinRT to project its API's to specific languages, so you can use the API from your language of choice, and it still looks like you're using your language.

Now here's the flipside, and the problem I see. WinRT right now is not really accessible to .NET, its accessible to Metro apps. And Metro apps are far limited in the API's they have compared to .NET. WinRT only has a subset of API's from .NET, like it doesn't include things like WPF, Silverlight, or WinForms because those don't make sense in WinRT. But the API's are severely restricted to API's that only make sense to Metro style apps.

I think the limitations and exclusions in WinRT are what make .NET developers feel like .NET is going out the window, and I agree with the concern. WinRT apps actually can only use specific API's, otherwise your app cannot be included in the App Store, and thus cannot be available to Windows 8 consumers.

I'm going to stop there. I hope this clears up some confusion. I like the idea of improving the Win32 layer with WinRT, but I think restricting the API's and favouring Metro style apps only is a very bad decision. Personally I am a fan of compatibility (Windows XP, Windows Vista, Windows 7) and am an avid supporter of the Desktop. I personally wouldn't use WinRT for any serious applications, that's my take.

FaultTrack on Kickstarter.
Includes in-depth information and a video.
http://www.kickstarter.com/projects/dcomproductions/faulttrack-a-modern-desktop-bug-tracker-for-net-de

Basically, I have been working on this project for almost two years now. I was inspired because I'm really passionate about software development, and I enjoy writing tools that make developers more productive. I've written other small tools that friends have used and really liked, but for this I took on something big.

I know most people just say "Ugh, another bug tracker", but I really want to provide something that just shines. The user experience and interface design for example, I've made look just like Visual Studio, but I've also used some Metro UI design principles for some of the interfaces. I think it turned out wonderful. I think most bug trackers today (but not all), have really bad user interfaces.

I also thought to myself... why can't we automate the process of capturing Exception information into a bug tracker, while debugging a project? Visual Studio already does this, so FaultTrack will to. Now that's a very high level explanation of it, but I think it could really be a great tool for developers.

Anyway, check out the link, the video and the project. I hope you guys really like it, because I'm very excited to work on it this year since its almost done.