Extending a native C++ project with managed code

One question that comes up from time to time in the newsgroups is ‘I have a native C++ project and I want to extend it with Managed code (e.g. Windows Forms). What do I do?’


The answer is not so complex. It is fairly easy to extend native projects with managed code. In this article I’ll explain how.


What NOT to do


To quote Kate Gregory ‘In the name of all that is good and right: Do not set /CLR for the entire project’.


/CLR tells the compiler that it should compile a source file as C++/CLI code in which it finds both native and managed C++ code. Theoretically you could specify this for the whole project, but this has some serious consequences.


Apart from the fact that it is possible for the compiled output size to explode, there can be significant problems with COM and CRT initialization. I am no interop expert in the matter like Marcus Heege or Kate, but I am willing to take their word for it.


Furthermore, your existing project is possibly validated by QA en unit tested 7 days from Sunday. You don’t want to travel that road again if you can prevent it.


What to do


You want to add managed stuff to your project while impacting the rest of the code as little as humanly possible. To achieve this you have to compartmentalize the managed stuff and give it a native interface that you can use in the native parts of you projects without any hassle.


I think I can best explain this with a practical example.


For the sake of this example I have a native DLL project that exports a function that returns an integer value. Perhaps this function got that integer value previously through an MFC interface, and now that value has to come from a Windows Forms interface.


Add the windows form to your project


This is the first and also the easiest step of the process. Rightclick your project and select ‘Add…->New Item’ and select ‘UI->Windows Form’ in the Visual C++ dialog.


You will then get a message box, telling you that your project will be converted to a managed project. Here you click ‘yes’. Even though you don’t want to compile your project with /clr, Visual Studio itself needs to know that you are doing managed stuff in your project. This is not necessary for compiling your project, but if you want to have the benefit of working with the forms designer and other .NET related things, then it would be a good idea. And you cannot add the form if you choose ‘No’ so it’s not like you have much choice anyway.


Now you have a .NET Windows Form in your code. You can verify the file specific settings if you want, but the cpp file will be compiled with the /clr flag set, and without the use of precompiled headers. Not using precompiled headers is important, because the default precompiled header is compiled without /clr set, and this would lead to conflicts.


Of course, if you need to, you can create a copy of StdAfx.h/cpp cpp files called ‘StdAfxClr.h/cpp’ add them to your project, and configure them to create a managed precompiled header, which you could then use for all files that are compiled with /clr. This is not necessary for small projects, but it could be a useful optimization in large projects.


 The interface layer


At this point you can compile and link the entire project, but your native code isn’t yet using the new managed functionality. And because the native code will not be compiled with /clr, it will never do so. In order to make that happen, you will need a thin layer between the native and managed code. This layer will have a native C or C++ interface which can be called by the native code, and a managed implementation that will do all the .NET stuff.


In our example, the interface is 1 simple C style function in Interface.h:


int __stdcall DoManagedStuff(void);


And this function has a simple implementation in Interface.cpp:


int __stdcall DoManagedStuff(void)
{
      DemoForm ^df = gcnew DemoForm();
      df->ShowDialog();
      return df->Value;
}


Interface.h and Interface.cpp are 2 new files that you have to add to your project. You have to manually configure the cpp file to be compiled with /clr, and to not use precompiled headers.


As you can see, the interface layer provides a clean native interface for the managed stuff that you want your code to perform. Of course, you are not limited to C style interfaces. You can also work with classes and make classes with a native interface and a managed implementation. But there are a couple of issues that you need to be aware of. If you want to go there, then it would be a good idea to read the paper written by Herb Sutter which explains the rationale behind C++/CLI, as well as some of the limitations and pitfalls.


Actually, reading that paper is a good idea for anyone working with C++/CLI who also cares about understanding what is actually going on behind the scenes.


Using the interface layer


All the hard work is done. Now you can simply include Interface.h in your native code files, and call ‘DoManagedStuff’ where appropriate.


#include “stdafx.h”
#include
“InterfaceLayer.h”
int __stdcall DoFoo(void)
{
      return DoManagedStuff();
}


Conclusion


As you can see, extending native code with managed code is not so hard. At least, it isn’t if you maintain a clean break between managed and native code. If you cannot do this, things might become more difficult. For example, using .NET controls on an MFC dialog, or using .NET remoting in a native COM project are things that can be much more tricky.


Another thing you should be aware of is that not all compiler switches can be used in conjunction with the /clr  switch. The compiler will inform you if it detects this. The combinations which are not allowed are documented, and can be found in the documentation of the /clr switch itself.


This post was not meant to be an exhaustive how-to to those complex scenarios, but instead an explanation behind the basic ideas.


The demo project for this article can be downloaded under the MIT license as usual.

5 thoughts on “Extending a native C++ project with managed code”

  1. I asked the C++ team about this a year or 2 ago, and they had no plans at that time to support mixed mode compilation on smart devices.

    I had to resort to making a native DLL with my native functionality, using only C style insterfaces (exported functions)

    Then I made a C# Library project, using PInvoke to import the native functionality into the .NET classes.

  2. Do you have a URL?

    Mixed mode refers to using the /clr compiler switch to compile a mix of native C++ code and managed C++ code within the same module. It was not possible with VS2005. I haven’t checked VS2008, but in April 2007 they had no plans to support it.

    Using other techniques to use native code in managed projects is called interop.
    COM interop is another way it could be done.
    In that case, the native and managed part are still split in different modules, but there is a runtime marshaler in between, performing all communication.

    It is not as simple as making a C style DLL as I described earlier, but it has the advantage that you can work with classes.

  3. Now, I can’t access to guy with that very interesting project.

    I work in mobile device programming sector. But some reason for to leave in C++ (big-big-big old C/C++ code). Then -> Native C++ (Smart Device projects). But I known, that big part of OS (Win CE, especially GUI-elements) has been written in .NET.
    IMHO: “native way” for using that elements – using Managed C++. But “Managed C++ in SmartDevice projects” – it is not easy…

    How can I do it? (very bad question, IMHO, but – “no way for me”:)

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>