Shared Projects, Common Libraries on Kinect for Windows V2 SDK Bits

Going back to my previous post, I thought it opened up an interesting idea around sharing code because I might want to build the class that I wrote into a class library and use it in more than one application environment.

When it comes to .NET, it’s possible to build a Kinect for Windows V2 application using .NET in 2 main ways;

  • Writing .NET code against the .NET Framework V4.5 (e.g. using something like WPF if you wanted to do something graphical).
  • Writing .NET code on top of WinRT (e.g. using XAML or Win2D or similar if you wanted to do something graphical)

The Kinect SDK folks have done a great job of making their object model look pretty much the same either way but, at least at some level, the underlying bits are different.

This has implications if you want to build layers on top of those bits and have them be available to both “pure .NET” and “.NET for WinRT” consumers.

As a simple example, let’s say that I want to write a reusable library that surfaces the following class;

namespace WindowsStoreLibrary
  using WindowsPreview.Kinect;

  public class SomeClass
    public KinectSensor GetDefaultSensor()
      return (KinectSensor.GetDefault());

Ok, it’s a largely pointless class but if I put this into a Windows Store Class Library project which targets Windows 8.1 as below;


then to make it compile I need to reference something that contains a KinectSensor type and there’s not one of those that I can reference.

There are two.

There’s the “.NET one” and the “WinRT one”.

it wouldn’t stagger me if I learned that, underneath, they end up loading up some native DLLs that are shared between the two but I don’t think that’s relevant here

To get that specific code to compile, I need to reference the WinRT component;


and I’ve then made a class library in the form of a binary assembly which can be referenced by Windows 8.1 projects but can’t be referenced by something like a .NET Framework project.

To take an alternate approach, if was to compile the same code into a .NET class library like the one called NetFrameworkLibrary in the screenshot below;


then, while the code looks the same, this code is targeting .NET Framework V4.5 and so I need to feed it a reference to the .NET assembly that provides the KinectSensor type;


To make this work I’m going to have to build two libraries with different references.

There are probably two approaches that I can take;

  • build portable class libraries that can span across both Windows Store and .NET Framework. the challenge there is that I’ll have to build a tonne of abstractions for the types from the Kinect SDK that I want to surface publicly from my own classes that live in those portable class libraries. that’s possibly a lot of abstractions.
  • make use of shared projects in Visual Studio.

This feels to me like a scenario where shared projects make a lot of sense.

as an aside, I think you need Visual Studio 2013 Update 2+ along with the Shared Project Reference Manager to follow the next part of this post

If I introduce a blank, shared project here named CommonCode and reference it from my other two projects as below;


then I think that gives me what I want – I end up with 2 binary outputs from the same, common source code and one of those can be referenced from a .NET Framework project and the other from a Windows Store project. I’d probably want to give them the same name in the real world.

It’s worth pointing out that on my system I had to add just a little conditional compilation to make that work because I still have this WindowsPreview.* namespace for the WinRT bits;


and I find it quite “illustrative” to toggle the navigation bar for this shared code between the NetFrameworkLibrary context and the WindowsStoreLibrary context and then hit ALT+F12 to peek to the definition of KinectSensor.

Here’s the definition when I’m in the context of my NetFrameworkLibrary (i.e. .NET);


and here’s the definition when I’m in the context of my WindowsStoreLibrary (i.e. WinRT);


which I think illustrates where these types are actually coming from.