Follow Up: Jeremy Likness on Windows Runtime Components in a .NET World

Jeremy Likness wrote this month’s feature titled Windows Runtime Components in a .NET World. A principal consultant at Wintellect and a seasoned Silverlight developer, Likness has been involved with Windows 8 since the initial Developer Preview, and started work at that time on his book, Building Windows 8 Apps using C# and XAML. He also started working with Wintellect customers that had built Silverlight tablet applications and hoped to port or rewrite their applications to run as Windows Store apps on Windows 8.

In his engagements, Likness found that there was a lot of confusion around the future of Silverlight, particularly with regard to Windows 8.

“A lot of companies were confusing the lack of a Silverlight-specific runtime with a general lack of support for their existing applications, when in fact the Windows Runtime provides a very rich managed feature set,” he explains. “I wanted to illustrate the flexibility of the new runtime and help developers understand they can use their existing skills to develop Windows Store apps and create Windows Runtime components. They have everything they need right now as managed developers to write apps for the new runtime.”

I took a moment last week to pose a few questions to Jeremy about his MSDN Magazine feature. Here is what he had to say.

Michael Desmond: Tell us about some of the challenges or issues you had to overcome in writing your feature. Did any surprises (good or bad) crop up?

Jeremy Likness: The key challenge for me was writing the C++ version of the application. I wanted to demonstrate a managed code component that can be reused by all language options for Windows Store apps, so part of that meant consuming the example in HTML/JavaScript and C++. Fortunately I have a solid Web-based development background, so the JavaScript examples were easy. With C++ I had to dust off some old skills – it’s been about a decade since I did any heavy native development – and also learn about the new libraries used to handle asynchronous operations. If there were any surprises, it was only how fast and easy it was to close the gap and get an example up and running.

Desmond: Could you provide advice related to your article that might help our readers going forward? In short, what actions can they take to avoid possible traps and to best implement what you've covered here?

Likness: My strongest piece of advice is to understand your intention for building a library and decide what the appropriate project is. I strongly encourage developers to consider managed class libraries for their components, especially because they can tap into the Portable Class Library (PCL) and build assemblies that can be used from Windows Phone, Windows Store, Windows desktop and Silverlight applications without recompiling. This is a very powerful mechanism for code reuse and fairly straightforward to apply to existing code as well.

Sometimes a WinRT component simply isn’t needed or practical based on the project. If it is needed, then I simply restate what I wrote in the article: the language choice should be driven based on the composition and knowledge of the team as well as performance needs. Some components require a native approach due to performance but the vast majority will work fine as a managed Windows Runtime component. In fact, I was told that the Windows Store Bing app uses managed components and it is a very well-performing app.

Desmond: What value have you personally gotten out of writing this feature? How does the process of writing an article like this one help refine and extend your own skill sets?

I always gain value when I write an article because it forces me to take a step back and look at the reasons for organizing a topic that way I do. For example, writing an article about managed WinRT components means thinking about when, why, and how I have used them in the past. I always learn more when I take a concept and present it to someone else because it’s important to break it down into individual steps.

For me, the article was also great because I got to take a slightly more advanced example using asynchronous code and wire it up in both JavaScript and C++. That experience gave me more insight into how those languages work with the Windows Runtime and also helped me dust off some old C++ skills. I always find it is important to always explore the reasons behind design and programming choices so that other developers can strategize effectively rather than just reading how to do something without the proper context.