We’ve been out doing the UK Microsoft Technical Roadshow and one of the topics that we’re covering is WinFX.

Coming to Presentation, Communication, Workflow Foundation(s) for the first time is pretty exciting in terms of how much power you get without writing tonnes of code and I think that’s particularly appealing to the C/C++ developer who you’d expect to have a very good appreciation of exactly how much time he/she is saving by adopting something like WinFX.

However, I’ve had a couple of pieces of feedback questioning whether any of the WinFX technologies are even usable from “unmanaged” C/C++ so I thought I’d say a little something about that here.

I think if you’ve got an existing C/C++ code base then you’ve got a number of options around how you start to integrate that with WinFX as you take it forward.

Firstly, let’s assume that rewriting all of your C/C++ code isn’t an option and you need to re-use large amounts of what you’ve already got.

I’d say you’ve got three main options;

1) Re-use your C/C++ code at the source-code level.

For me, this is about writing C++/CLI or managed C++. Here, you can start to add additional source to your projects that will be compiled as .NET code rather than native code and you can end up with binaries that are either pure .NET or, more likely, a mixture of .NET and native code living in one address space. You can add new C++ code that creates .NET types and from those .NET types you can use your unmanaged classes just like you usually would. Now, combining these two worlds together like this is going to add some complexity (you’ve got .NET types, native types, the managed heap, the unmanaged heap, etc.) so it needs some thought up-front about which parts of your application stay unmanaged, which are managed and how the code-base is structured to reflect that and so on. However, it’s definitely something that you can do.

In terms of resources;

You can find a tonne of information about C++/CLI here.

There’s also a great new article here which focuses on this kind of technique. As you’re reading the article you can logically be replacing “Windows Forms” with “WPF” or “WCF” in terms of using .NET technology from C++ code.

2) Re-use your C/C++ code at the binary level

Your binary options largely come down building your C++ into COM objects or plain old DLLs. If you can expose your C++ workings as DLLs then you should be able to write something like C# or VB (or C++/CLI) and re-use that functionality through platform invocation. You need to take some care as to what kinds of data types you’ll be wanting to pass across that PInvoke boundary (i.e. the simpler the better) and also how many times you’ll be needing to cross that boundary (i.e. the less you do it the more performance you’ll get) but with some thought about how to build your DLLs and which code needs to live where you can make that work.

If you already exposed your functionality through COM then you can generate .NET wrappers for those COM objects fairly easily although, again, you need to consider the “gap” between types that are pretty easily used from COM and those that are easily accessible to .NET to make sure that you don’t end up writing a tonne of “COM code” inside of your C#. You also need to consider that boundary-crossing again to make sure that you get decent performance and the differences between the non-deterministic finalisation of the .NET world and what that means for COM objects.

In terms of resource on this kind of technique, I find the PInvoke Wiki invaluable but, depending on your needs you’ll probably need to spend some time reading how PInvoke works generally or very specifically.

3) Re-use your C/C++ code at the service level.

Here, I’m thinking about a scenario where you write .NET code and it doesn’t really make direct use of your existing C/C++ code base because you’ve hidden that code behind some kind of service layer (perhaps by sticking it behind IIS and exposing its capabilities by POSTing XML to it or perhaps by using one of the other techniques above to put something like a Windows Communication Foundation facade onto what you already have). In many ways, this is probably the simplest thing that you can do but it depends on whether your functionality and code-base lends itself to being partitioned up in this way.