There is a ton of discussion going on around the announcements at //BUILD/ this week and what the implications are for Silverlight developers and for the future of Silverlight itself. A lot of that speculation has quickly sped to the realm of FUD. As a Silverlight MVP, I for one thing the future is quite bright and shiny for Silverlight developers, and even for Silverlight applications in terms of moving to the new platform and building Metro style applications.

If you have no idea what a “Metro style” application is or what WinRT is, you have lots to read. The short story is that a WinRT application is one built for codename Windows 8, and one that runs with the new user interface style and experience called Metro. Just go check out some of the many videos available now of Windows 8 to get a better sense of what this means. But from a developer perspective, it mean you build a client app to run against the new Windows runtime (WinRT), and it is not a .NET Framework application. There is a lot more to say there, but that is for other posts. What I want to focus on here is what it means at a high level for Silverlight developers.

If you are a Silverlight developer, here are a set of characteristics of your application that you have to deal with on every Silverlight app you write because they are part of the platform:

• It is a XAML-based user interface application, with code behind in C# or VB
• The XAML that you use is a constrained set of XAML compared to WPF – there are some capabilities missing, even in SL5
• It runs in a security constrained sandbox by default, with constrained access to underlying machine capabilities
• Anything in the platform API (Silverlight) that might take “a while” is only exposed as an Async API

So what are some of the things we can say about developing Metro apps at a high level? These same exact statements about the platform hold true for Metro, they just have some slightly different manifestations. This means that not only will developing applications for Windows Metro feel familiar and comfortable to Silverlight developers, more of their code will be portable to Metro applications than other .NET UI applications.

Now I am not saying your Silverlight apps are going to “just run” or that you won’t have to do some non-trivial porting to turn a Silverlight application into a Metro application, but there will be a lot less impedance mismatch there than there will be for your typical WPF or Windows Forms application. Those applications will likely have tons of code that is doing synchronous things that have to become async, and probably also use parts of the .NET Framework capabilities that just wont exist in WinRT, at least for the first release.

However the kinds of capabilities that are in the Silverlight plug in and its supporting libraries are exactly the kinds of things that WinRT will support, just with different namespaces, type names, and some different API member names and arguments.

So the kinds of things you will have to change to port your application if it is well designed will include:

• XAML – there are new controls to comply with the Metro look and feel, but they follow very similar patterns to existing ContentControl and ItemsControl derived controls in Silverlight
• Code that touches the Silverlight framework APIs themselves – but this should be fairly straightforward if you are not too exotic in what you do
• Any COM/PInvoke code

So while it is not going to be “just a weekend project” to port a significant Silverlight application to Metro, a well designed and layered Silverlight application should also not be anything close to a total rewrite. Significant parts of things like model objects, view models, service calls, and application logic should just recompile to WinRT. Significant parts of your XAML and XAML resources can probably still be used as-is. The rest should have fairly straightforward porting paths since the underlying platforms are really very similar.

Now I should caveat this with the fact that I have not sat down and done a significant port of any Silverlight apps I have yet to validate this perspective. I plan to dig into that over the next few weeks and will definitely continue to share my perspectives. But at least from what I have seen at the conference, I’m not sweating it. I like what I see and I am looking forward to continuing to use the skills I have invested in Silverlight and WPF to start building Metro apps.

Thursday, September 15, 2011 11:40:05 PM (GMT Standard Time, UTC+00:00)
Comments [60]  |