05 June 2014
Many articles will tell you that you cannot have a C# back end for an HTML5 presentation layer. While this is true on the surface because you cannot mix them in a project, it is still possible to mix-in C# (or VB.NET if you are a verbose kind of person) as a “Windows Runtime Component.” Since I came into my first Windows 8 project with an ASP.NET MVC mindset, this is the route my team and I took. In retrospect, this might not have been the best idea because of the many limitations and oddities that added complexity. Depending on your team's skill-set, this may or may not be an option for you. However, you should consider the following.
WinRT is a Subset of the Full Managed Library
- All public classes must be sealed. This means that there can be no inheritance in classes that are exposed publicly and increases the amount of boiler-plate code.
- Generics cannot be exposed publicly
- All types in the public signatures of a component must be Windows Runtime types.
- All public types must have a root namespace that matches the assembly name. (This is something that Java has done for all projects from the beginning.)
- All parameters are either for input or for output. There are no ref parameters. This is especially important when passing arrays.
- Overloading methods is more involved than in managed code.
- When throwing an exception, you cannot do it as precisely as in managed code.
- There is no inheritance in public types, therefore you cannot define exceptions for specific scenarios.
- Although it is best practice to throw ApplicationException from your custom managed code, there is no such type in WinRT.
- Raising/handling events is a bit more complicated than in managed code, but they are more important because of the asynchronous nature of WinRT.
Debugging has Limitations
Open-Source Options are Limited
Do not expect to be able to use all of the open-source libraries that you are accustom to. Few libraries are compiled to work on WinRT. Some can be downloaded and recompiled to work, but most would have to be virtually rewritten to compile for this run-time. To reference class libraries, they have to be compiled against 4.0 or 4.5. However, even when you are able to reference a class library and compile your project, it doesn't necessarily mean that it will not result in a runtime exception.
Not being able to use open source libraries can be somewhat of a good thing though. This is because many of those libraries are too large/heavy for what phone and tablet applications should be. However, for my first Windows Store application, it was a bit of a hindrance to provide some of the features that we initially thought would be easy.
When trying to determine whether or not a library will work for your project, do not rely on NuGet as the deciding factor. Since the manifest for NuGet projects specify a runtime, most will simply fail to install. If the library can be compiled in 4.0/4.5 and has minimal dependences, it might just work.
is licensed under a Creative Commons Attribution 4.0 International License