Unmanaged to Managed Calls

• Download source - 10.1 Kb

Introduction

If you're developing in a pure .NET environment count yourself lucky. Many of us are still working with languages that, nicely put, are somewhat less than recent. Many have vivid memories of working with software like FoxPro 2.6 which is roughly 10 years old. Unfortunately, in these environments starting over isn't always possible, and so integration of new technology is often a necessity. It can often save development time, provide more robust solutions, increase efficiency and speed, or even preserve your sanity when you're asked to modify that 'particular' application.

One such integration solution is to make your .NET libraries available to existing code through the use of exported functions which reside in a managed C++ bridge dll. In many instances this solution proves adequate and even simpler than other such techniques using COM and other facilities that may or may not be available to you.

The .NET Library

The first thing to do is to develop a .NET library for your required task. There are a variety of ways to expose your .NET solution but the simplest is probably via a class library which is the method used here. Keep in mind that you'll need to provide access to this library through your bridge dll. You may be fortunate enough to be able to expose that library through a single function call (i.e. 'object.do_this' ). However, you may need to preserve state between your calling application and your library, using handles, argument passing, etc.

A tip for those of you unfamiliar with the conversion between managed and unmanaged types; you may want to increase your effort to minimize arguments to the functions which will be called by your bridge dll. Minimizing arguments can often save headaches. Conversion of arguments from unmanaged to managed types and back again (if arguments are begin returned) can be one of the most time consuming parts of the process.  You may be using char *'s, CStrings, arrays, etc. They each have their own intricacies.  Once you've done it a few times though it becomes less of an issue.

The Bridge

The bridge is simply a managed C++ dll in which you export functions with the familiar dllexport attribute. From this dll you'll access your .NET library. Once you've included your .NET dll with the #using directive and optionally imported the namespace, the facilities in your .NET library are available to use. You may need only a single exported function here to provide access to your library, or you may need several. You might want to keep your bridge dll as simple as possible, a bridge only. However, you may want to provide facilities within the bridge specific to the interaction between the calling application and the library. This may provide a more elegant solution for those attempting to implement isolation and data hiding techniques.

The Calling Application

The calling application simply requires the ability to load a dll and make calls to exported functions. The example given in the source is a simple unmanaged C++ console application. It makes calls to several bridge functions and prints the output to the console window. 

The rest of the details are left to the source code which can be downloaded above. The process is relatively simple and so the source included should provide more than enough detail to get you started. Coordinating 3 projects during the debugging process can be tricky so they have all been included in a single solution with a common output directory (/common) in the root of the solution. The bridge dll and console (calling) application build debug output to the common directory. However, the vb.NET library build will not do this so you will need to copy that build to the common directory. All of the paths in the solution are relative, but be sure to check those if you encounter any problems, especially those related to dlls not being loaded, etc.

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)