WinRT and .NET: What is it, where do i place it and what does it change

So I'm reading up about the differences between the old and the new APIs, and I can't find whether the new WinRT API will provide for desktop apps, so far it seems its only available to write Metro apps - ie the full screen, 'phone style' apps.

All WinRT more or less is a modified library similar to Win32.

WinRT is the Metro version of Win32, they took a great deal of complexity away from it, and made it easy to work with.

Does this mean that I can write a WinRT-based app and it will be invoked from a desktop but display like other Metro apps (eg IE) and I won't be able to write an old-style desktop app that runs in the old-style desktop?

In theory you would write a desktop application and add WinRT code in order to display a Metro style UI when the user requested it.

What does this mean for server side apps? I imagine WinRT would be the API of choice for servers, now that Windows Server comes with an optional GUI, so I imagine that if I can write a windows-less app using WinRT for the server, I should be able to write the same for the client too? (and if that's the case, surely I could connect a non-Metro UI to it)

Don't guess...Power Shell( the name escapes me if this is wrong ) is still king in Windows Server

How I Learned to Stop Worrying and Love the MS-Stack

You can still run VB6 apps on windows 8. Retro-compatibility for good or bad has always been a trend in the MS ecosystem. You shouldn't worry about the survival of technologies like WPF / Silveright, and even winforms for that matter.

On the other hand, you have to accept that for a long term project, you will never have the latest, cutiest technology.

In fact the questions you should ask yourself about the choice of a technology are :

• Is my team comfortable enough with that technology to be productive?
• Is my team happy to use that technology?
• Can I recruit people for that technology?

That's the combination of the answers to this questions that should lead your choice, and not the trends forged mainly for marketing reasons.

For more about this thematic of ever-changing technology, you should read "Fire And Motion" By Joel Spolsky :

The companies who stumble are the ones who spend too much time reading tea leaves to figure out the future direction of Microsoft. People get worried about .NET and decide to rewrite their whole architecture for .NET because they think they have to. Microsoft is shooting at you, and it's just cover fire so that they can move forward and you can't, because this is how the game is played, Bubby. Are you going to support Hailstorm? SOAP? RDF? Are you supporting it because your customers need it, or because someone is firing at you and you feel like you have to respond? The sales teams of the big companies understand cover fire.

And that was written nearly ten years ago.

Architecture and Technologies

Architecture and Technologies are two separate things and choices to do :

• You can do MVC with winforms.
• You can do MVVM with WPF/Silverlight.
• You can do MVC with ASP.NET.
• You can do whatever you want, including MVC and MVVM, with WINRT as far as we know.
• You can go functional with F#. Why not ? There are domains where it would make sense.
• You can mix all of them, to have different entry points to a common system, then be mocked because it gets too complicated, etc.

You can use services, resources, third party controls, ORMs, etc. with all this technologies, and maybe, or maybe not, with the next ones.

You can twist and bend MVC in many ways with all those technologies : Binding or not ? code behind view or not ? Controller or not ? ViewModel everytime or only when needed ? There are so many ways to implement a design pattern, even within the scope of one specific technology.

That would be irrealistic to force you into one of them without advanced knowledge of your project and team. It would only be based on personal preferences, and would end-up in a "my technology is better than yours" showdown.

The only thing that can be honestly and objectively suggested is to use the best practices you can apply to create an architecture that will stand the test of time, and maybe, really maybe will be portable or reused at least in parts with a future unknown technology. And that upgradability/portability shouldn't even be the main purpose of your architecture.

The main purpose of your architecture and choosed technology is to deliver a product to your boss/customer that meets his realistic requirements.

MVC (and it's younger brother MVVM) proved more and more to be a basis for robust architecture since 1979 in the OOP languages arena and beyond. But choosing what specific technology should be used in a 10 years long project should remain your decision.