Top 3 WinRT needs for .NET developers

WinRT resized 600

WinRT is the new Windows 8 runtime used to create Windows Store apps. WinRT provides language projections (bindings) for C#, Visual Basic, C++, and Javascript.

Loosely speaking, WinRT can be thought of as an object-oriented sandboxed secure replacement for Win32.

In my view, the top 3 WinRT .NET needs are as follows:

Update:  Thanks to Jayson Go for pointing out that Need #1 now works. I am very happy for this feedback. In fact, it is the best that I have gotten since I started blogging over two years ago. Thanks again Jayson! I will follow-up with a link and an example.  For now, see the comments below.

Need #1: Allow async in Interfaces
Interfaces are contracts that a class or struct can implement in its own way. Interfaces help separate the contract from the implementation. Interfaces provide a powerful mechanism that helps make dependency injection easier (and some would argue even possible). Interfaces can also help to reduce dependencies in general. They also make Test Driven Development easier by enabling clients to bind to a contract—not a concrete implementation. This way, it is easier to introduce a test double.

C# 5.0 introduces two new powerful keywords (async and await) to help make asynchrony easier. The problem: only a method can be modified with the async keyword. This includes anonymous methods, and lambda expressions. This does not include a method definition in an interface however. This is a problem because you will not be able to call an async method when expecting an interface type.

This is the #1 need, in my view, because interfaces are a key architectural mechanism when implementing services, repositories, facades, roles, partial views, etc.

If you are using Javascript, then this will not be a problem. Javascript uses promises to handle asynchrony.

Use inheritance with no interfaces.

Soft cast—not pretty.

Bridge pattern from the Gang of Four 

Need #2: Mock testing framework
Mock objects are simulated objects that mimic the behavior of real objects in controlled ways. A programmer typically creates a mock object to test the behavior of some other object, in much the same way (Source). 

Currently, there are no mock testing frameworks such as RhinoMocks available for “Windows Store” app development.

The reason: there is no dynamic proxy generation due to a missing namespace in the “Windows Store” profile: System.Reflection.Emit.

Use other kinds of test doubles such as fakes and stubs instead; this has been my approach.

Microsoft Fakes, is a new framework that generates test code for interfaces instead of dynamically mocking them but in a mock like fashion.  Microsoft Fakes is only available in Visual Studio 2012 Ultimate.

MoQRT like Microsoft Fakes in that it generates the test code for an interface instead of dynamically mocking them.

Need #3: ADO.NET and other APIs
The API for “Windows Store” apps is very tight and does not contain ADO.NET and Entity Framework. Mobile apps should also work when you are offline. Since WinRT is the future platform for Windows development, then there will be very sophisticated apps developed with WinRT. Sophisticated apps need sophisticated storage.

The WinRT profile is a significant subset of the full .NET 4.5 profile. In addition, many classes were moved into the Windows.* namespace (WinRT) which helps make them available to C++ and Javascript. This just creates an exercise in mapping the old to the new.

On the other hand, WinRT is tight. We are back to time where it is possible for the system to be understood by a single person.

Storage alternatives; these bits are even fresher than WinRT’s so be aware:

Despite the needs, tooling is not a problem for Windows 8 development. I have been developing with Visual Studio 11 (2012) and Windows 8 since I was given a prototype tablet about a year ago at Build by Microsoft. These needs have been on my mind since.

Please share any new frameworks or workarounds that you discover, and also the needs that are at the top of your list. I want to hear from you.