I was recently tasked with creating a Windows Store (Metro, WinRT) version of an existing app. This is my first WinRT project. Documenting my experience so far:

1. So called “universal apps” are not truly universal. They actually consist of several platform-specific projects that may share some code. There is no true binary or even source level compatibility between Windows Phone and tablets/laptops/desktops.

2. WinRT platform for desktops/tablets/laptops does not have a name. This causes confusion and awkwardness when describing things. Visual Studio often calls it “Windows 8” or “Windows 8.1”, and sometimes just “Windows”. The latter is utterly unacceptable. When you see “Class Library (Windows)” the last thing you think of is WinRT for desktop. Compare this to well-defined things like “Silverlight”, “Windows Phone” or “WPF”. For the rest of this blog post I will call WinRT for desktop “Metro UI”.

3. Portable class libraries must explicitly specify target platforms. A portable library may use only the APIs available on all targeted platforms. The more platforms you target, the smaller the set of available APIs. All assemblies referenced from the portable library must be available on all targeted platforms.

4. Using 3rd party libraries plunges you into DLL hell. If you develop a large universal app, you may want to put most of your code in a portable library or libraries that target both Metro and Windows Phone. The catch is that your libraries may reference only other portable libraries that target both Metro and Windows Phone. It may be hard to find a proper version of your favorite 3rd party library. Even essential things like Unity exist only in pre-release. Some vendors ship two different libraries for Metro and Windows Phone – your portable libraries can reference neither. If you want your libraries to be loaded/processed by existing .NET tools (e.g. nUnit), they must target Metro, Windows Phone and .NET. This reduces the list of available 3rd party software to virtually nothing.

5. Unit testing is screwed. You can reference nUnit from a portable library (not sure how it works), and even write some tests, but you won’t be able to execute those tests. At the time of writing no nUnit test runner is able to load Metro libraries. Both ReSharper and standard nUnit refuse to cooperate. After all, they are standard .NET apps, and you ask them to load a portable library not targeting .NET. If you do make your library target .NET, you can’t reference any 3rd party software – see previous paragraph. Fortunately, Microsoft Test does work with Metro libraries.

6. Mocking is totally screwed. Neither Metro nor Windows Phone allows generation of dynamic mocks. This makes the vast majority of mock libraries useless. There is a rumor that library named “FakeItEasy” works, but they are yet to be verified. You could use mocking if you make your libraries target .NET, but you don’t want to do that – see paragraph 4.

7. Continuous Integration is difficult. I think the word “cross-compiler” is considered obscene in Microsoft. Metro apps can be compiled only on the client version of Windows 8 or 8.1. Even Windows Server 2012 does not work. So, you won’t be able to use your favorite Continuous Integration server that runs Windows 7 or any version Window Server. You will have to setup a new CI machine, or perhaps use something like Visual Studio online (to be verified).

8.Metro UI XAML is closer to Silverlight than to WPF. The XAML dialect found in Metro apps is relatively poor and resembles first versions of Silverlight. No Label, no DockPanel, and, most annoyingly, no MarkupExtesions. Argh.

Bottom line: there is no really a one word bottom line. Some things are nice, but some cause pain. I guess one of the issues is lack of interest and market share, which makes Metro UI look less developed than Silverlight, let alone WPF.