Migrating C# DLL Library to WinRT Component project

In order to make the functionality of your C# or VB.NET class library (DLL) available to other WinRT languages (C++, JavaScript) you need to convert it to a WinRT component (http://msdn.microsoft.com/en-us/library/windows/apps/br230301.aspx). The referenced MSDN article lists the areas where coding for a component and a library is different. Here are some ‘best practices’ I found useful on a recent project:

1. Reduce number of interfaces requiring conversion: very often when developing class libraries, developers do not pay sufficient attention to the visibility of classes and their members. Before starting the conversion review your library to make sure that only classes and methods that are needed by outside clients are marked as public. Otherwise, you will be putting effort into fixing method signatures and possibly implementations where you don’t need to.

3. Anonymous dynamic types: don’t use them! Your WinRT component will compile and even work with .NET clients but not with C++ clients. Use dictionary lists instead. In certain cases, for example when using async (awaitable) methods and using dynamic arguments or return values you will get runtime errors which seem unrelated to dynamic types (‘object does not contain a definition of ‘GetAwaiter’) but in fact can only be resolved by removing the dynamic types.

3. Unit testing: it is possible to use InternalVisible attribute to unit test non-public members of a library. That does not work with a component: you can only unit test public members. Therefore, keep two projects: one for the WinRT component and one for the DLL library and share source code between them using compile time flags. You can then continue to use unit testing to test internal members.

Leave a comment