17

I never actually built an application (nor a HelloWorld) in WinRT, and I'm very suspicious.

My question is if there are features in WPF/Silverlight that don't exist in WinRT (excluding features that are implemented differently by design)?

And these aspects are most important to me and are the core of my question, and in result, decision to whether start using WinRT or wait for these to be implemented for it:

  • Entity Framework?
  • WCF RIA?
  • MVVM support (Prism)???
  • Various toolkits (Silverlight/WPF toolkit), that provide additional controls such as DatePicker etc.?

It's not clear to me whether WinRT fully targets .NET or how it works.

Also, is WinRT a client-only (like WPF) application or can be ran on a remote client while sitting on a server (like Silverlight)?

Another one: What about backwards compatibility, if I develop a WinRT app, will it ever be able to work on Win XP?

I anyway can't understand why MVVM is not integrated inline and has seamless IDE support as MVC has. but that's just a side note. I can't use XAML without MVVM, any app that is a bit bigger than hello world is easier to do with MVVM.

Update after answer

As I commented on the answer, I do like the design of WinRT, but the question remains unsolved until I know about the specific technologies mentioned above (EF, WCF-RIA + Validation, MVVM, SDKs and Toolkits). And obviously, I'm not gonna start selling WinRT apps or digging into it until I have the above techs as a least.

Conclusion, as one who most of his work is LOB apps, after checking around a bit, HTML5+JS is far from being an alternative to SL. So for conclusion, I stick to SL and keep on recommending it to my customers. SL takes the least development time, and is bug free. Javascript is a dirty error-prone language, no pattern and no nuttn, compared to C#.

Once EF+RIA+Prism+Toolkits are fully supported for WinRT, I will consider taking my LOB apps the metro way.

Community
  • 1
  • 1
Shimmy Weitzhandler
  • 101,809
  • 122
  • 424
  • 632

2 Answers2

33

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 :)

Community
  • 1
  • 1
Rich Turner
  • 10,800
  • 1
  • 51
  • 68
  • I've read about the WinRT, and I do love the changes in the API, especially those related to async. Any case as long as the feature exist, I don't care how to write it as long as I don't have to write it myself. So I might start experiment with it and feel it, but won't write any real app as long as I don't have: Entity Framework, WCF RIA client-server generation including validation, Prism for WinRT (Sorry, I'm not into becoming famous by developing my own MVVM framwork, Prism is best for me, I love it :p). So my question is specifically on the three technologies I pointed out. – Shimmy Weitzhandler Mar 30 '12 at 00:16
  • And BTW, I disagree with your statement "*I don't think it's Microsoft's job to write every framework for every scenario*", MVVM is accepted in XAML just as MVC is in ASP.NET and thus, it IS MSFT's job to encourage it and develop IDE tools to make its use easier. – Shimmy Weitzhandler Mar 30 '12 at 00:22
  • I would really question about Win32/WinRT relation. I really believe WinRT runs on top of kernel itself, completly bypassing Win32. Maybe for quicker development / testing, they build it on top of Win32. But in the future, this might change. Simply because it is prohibited to use Win32 from Metro applications. – Euphoric Mar 30 '12 at 05:55
  • Which MVVM framework do you think Microsoft should most closely mimic from this lot? http://en.wikipedia.org/wiki/Model_View_ViewModel#Open_source_MVVM_frameworks. Microsoft shouldn't be expected to create a competitor to everything on the planet. Case in point: Microsoft COULD have created a competitor to jQuery. Thankfully, they didn't. They've published a ton of guidance and tooling and support a variety of open-source MVVM frameworks. That's the right thing to do. – Rich Turner Mar 30 '12 at 08:55
  • @RichardTurner, OK. although I don't like it, I agree on the MVVM part. So for conclusion I don't care about WinRT as long as Prism has not yet targeted it, also the other issues I mentioned. (EF, RIA, SDK & ToolKit). – Shimmy Weitzhandler Mar 30 '12 at 14:32
  • Another way to think about WinRT is: Can you afford to ignore it just because there isn't a mature feature you currently depend upon? Could you, perhaps, leapfrog your competitors by creating beautiful Metro apps that utilize your existing infrastructure & assets? Could you start simple and build sophistication as your experience grows and as additional tools and libraries, etc. emerge? Only you can answer that, of course ;) Good luck! – Rich Turner Mar 30 '12 at 17:39
  • @richard ok but Shouldn't all solution be structured with async loading, service and DI *already*.... So I don't quite see what more it gives. Better tooling ? May be.... the platform ? It seems people have to just change their is and start from scratch. Chance of that ? 0. So it looks like a dubious added value PLUS there is just no market to begin with. Is it a masochistic thing ? – nicolas Aug 12 '12 at 21:28
  • @RichardTurner - did you mean this link: http://channel9.msdn.com/Events/BUILD/BUILD2011/TOOL-810T or this link: http://channel9.msdn.com/Events/TechEd/NorthAmerica/2011/DEV324 for the "Async Made Simple" URL? I believe you meant the first, but I could see where the second was applicable. The link in the answer is botched. –  Sep 07 '12 at 19:23
3

Please note that WinRT targets Windows 8 Metro-style applications NOT conventional desktop applications (Windows 7) developed with WPF or Winforms. Metro-style applications will be distributed through the Windows Store ONLY. Microsoft charges 30% for Windows Store applications. Developers get 70%. This is the same 'tax' that Apple charges. Forget about Silverlight for the Metro-style version of Internet Explorer. It does NOT support plugins. Remember Silverlight IS a plugin. The desktop version of Internet Explorer supports plugins, hence Silverlight.

Steven Licht
  • 760
  • 4
  • 5
  • You didn't get my question. I don't mind moving to WinRT abandoning SL, I just wanna make sure I have the technologies mentioned in my question. – Shimmy Weitzhandler Mar 30 '12 at 14:31
  • Regarding the "Tax": The comission MS charges reduces to 20% after you've made $20K. But even at 30%, this is typically FAR less than one would end up discounting a boxed product in order to get it into the retail channel and can account for FAR less than is often required to distribute your apps electronically, handle payment, handle servicing, etc. – Rich Turner Mar 30 '12 at 17:42
  • @Steven Will you be able to deploy WinRT apps off the market? – Shimmy Weitzhandler Apr 22 '12 at 01:38
  • 1
    I can't understand how msft can do such obvious mistakes, and pull out brilliant investment in some other areas. – nicolas Aug 12 '12 at 21:33
  • the reason preventing me from switching to winrt is winrt apps will only be distributed through windows store. which nobody have. – Syaiful Nizam Yahya Apr 18 '13 at 03:39
  • @ PublicEnermy, it may not be common yet but everyone with windows 8 or a windows mobile 8 device will have access to it – MikeT Sep 30 '13 at 14:15