WinRT is basically a collection of COM objects that wrap a bunch of Win32 API', exposed as CLI-compliant assemblies.
Microsoft modified their C++ compiler to consume and generate ECMA 335 (i.e. CLI) metadata rather than the more traditional and (largely) C++/COM-only MIDL or lib file formats. Microsoft also modified their "Chakra" Javascript engine to also consume and emit CLI metadata.
This means that when targeting WinRT, Javascript and C++ code, along with .NET languages, of course, can consume CLI-compliant (i.e. .NET) assemblies and can emit CLI-compatible (i.e. .NET) assemblies.
So, one can write WinRT code in C++, any .NET language (i.e. C#, VB.NET, F#, Iron*, etc) and in Javascript.
The WinRT API's will be VERY familiar to you if you've ever written any .NET code. The Windows team actually sought the help & guidance of the .NET Framework design team when designing WinRT, so the same design guidelines that have guided the entire .NET framework team and most of the .NET community for the last 11 years have been applied to the WinRT API's.
WinRT is, quite frankly, beautiful :)
WinRT's primary impact is that it replaces System.IO's file, network, stream IO classes with similar API's but which ONLY support async IO. This means that you will not be able to write apps that block threads while they wait for calls to the filesystem or external systems via the network to return unless you take explicit steps to do so.
This is a GOOD thing.
Luckily, the new async/await features of C# v5 & VB.NET v.next, along with specific support for C++ mean that you don't have to go and fundamentally change how you write code in this new async world - typically you just need to add an "async" keyword to method signatures that call async API's and then use the 'await' keyword prefixing each async API call.
I STRONGLY encourage you to watch Anders Hejlsberg's session which should make this whole thing very clear. While you're there, I also encourage you to watch several of the other //BUILD sessions, especially Harry Pierson's talk on using WinRT with C# & VB.NET and Mads' session on Async Made Simple in C# and VB.
I'd also recommend that you take a look at the improved Win8/WinRT platform architecture diagram that I blogged a few weeks back which should make things a little clearer.
As for .NET itself, as I articulate in my post above, .NET is not "going away". While a few of the .NET API's will be prohibited in WinRT apps (i.e. blocking IO API's), most of the API's you depend upon remain and are fully accessible.
Regarding Silverlight: Silverlight is a browser plug-in. It's a modified-subset of WPF and offers some very powerful and attractive features. So much so, in fact, that the Silverlight XAML engine was moved into the core Windows team and is used for most of the Metro UI rendering in Windows8 - even by the OS itself!
The net result is that most of your Silverlight code will run just fine with barely any modification, other than just changing a few 'using' namespaces.
There are a ton of XAML-focussed sessions from BUILD available to watch here.
With regards backward compatibility, aim to:
- Isolate code that you want to use in WinRT as well as in .NET desktop apps, Windows Phone, etc. into Portable Assemblies wherever possible.
- Abstract code that needs to take specific platform dependencies and consider manually loading them or using IoC to compose your modules together.
Frankly, I don't think it's Microsoft's job to write every framework for every scenario. There are several MVVP approaches/frameworks out there in the wild from various people with various pro's and con's. And if you don't find one then create one and stick it up on GITHub and become famous ;)
Above all, though, there's little stopping you from downloading and trying Win8 Consumer Preview & Dev11 Beta. Go get them and try them out - I think you'll find them very refreshing :)
HTH.
Update#1 in answer to the specific support for EF, WCF, etc:
You can find the WinRT API surface area enumerated here in some detail. The core WCF API's are enumerated here.
Note, however, that Microsoft is strongly recommending against using network coomms to communicate between Metro apps and other metro apps or desktop apps/services on the same machine. Read this SO question & Kate Gregory's answer - she links to a video where this scenario is discussed in detail.
If you want to communicate with off-box network services, then you have a wide variety of options including WCF, sockets, etc.
Regarding RIA: Microsoft are currently saying that if you want data, you'll need to get it via a service rather than directly from a DB. There's no ADO.NET for Metro and the recommendation is to surface data via OData, JSON, XML/HTTP, etc. Data as a service is very much a RIA scenario, so I expect RIA to be well supported for Metro apps. Here's a BUILD session on this very subject which may shed more light.
Only you can tell whether or not your specific scenarios are supported in WinRT. I think your best bet would be to download the bits and start exploring.
Update 2 following P&P's updated roadmap and guidance:
P&P have recently published a new roadmap and guidance for building Windows RT / Windows 8 "store" / "modern" LOB apps.
This guidance includes updates to Prism/Kona and also includes EntLib6 & Unity3 (IoC). I encourage anyone interested in this space to study the published materials and reference apps - there is some great stuff in there :)
Best Answer
I haven't ever had that problem before with similar technologies (such as ClickOnce). In fact I've found the opposite. In general users are more comfortable with software if they have to answer less questions.
For the majority of users out there they simply don't care where an app is installed to. And most don't even understand the consequences of choosing one location over another.
Why burden users with choices they don't care about and can't answer in a meaningful way? I know it's not true of every user, but IMHO, it is for the majority.