Windows 8 Development - C# Components for JavaScript Applications

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

First of all, whether you call it from JavaScript or C#, WinRT APIs are not the same thing as the .NET runtime. Do not expect to have all of .NET’s functionality. WinRT applications are heavily sand-boxed and opinionated toward asynchronous operations.

Marshaling Limitations

When marshaling between JavaScript and C#, there are many limitations and confusions that have to be remembered and worked around. From what I can determine (based on errors that I have received), this seems to be because the marshaling between the two technologies is done via COM. Here are just a few restrictions and oddities:

  • 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

While it is possible to debug your components while running your Windows Store application, you have to chose what you are targeting. You can either debug the JavaScript or the managed code. You cannot debug both at the same time.

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.