Michael Jones, PhD

« building and using a DLL in C++ in VisualStudio 2005 | Main | The Ups and Downs of Mac laptops »

December 26, 2006

Finding entry points when importing from a self-made DLL in C#

Merry Christmas to everyone, I hope yours was as good as mine. We had a great time at home with our 3 year old twins.

The next technical challenge was importing from a self-made DLL (created in C++) in a C# application. I set it up and ran the program only to get "entry point not found." The problem was that the C++ compiler mangled the names of my functions. This feature (it's not a bug) was not well documented in the dll-import literature but I suppose I should have known it anyway. There are several ways to get around this.

The first is to enclose funtion headers and bodies in "extern "C"" blocks in the exporting C++ files. This prevents the names from being mangled. This is pretty straightforward.

The second is to use dumpbin.exe to examine function names in the dll. I found dumpbin.exe in C:\Program Files\Microsoft Visual Studio 8\VC\bin but needed to add the location of mspdb80.dll to my path environment variable (that's in Control Panel | System | Advanced) to get the thing to run. dumpbin.exe /Exports and not dumpbin.exe /symbols gave me what I wanted. After finding all that the C# import declarations ...

[DllImport ("mydll.dll", EntryPoint="#2")]
private static extern int myInt();

gave me what Iwanted because myInt was listed second with ordinal #2. Also,

[DllImport("dll-tests.dll", EntryPoint="?myInt@@YAHXZ")]
private static extern int myInt ();

did as well because that was the mangled form of my function name. And, just to bring this full circle, after I added some extern "C" blocks to my exporting C++ files, the import went down as...

[DllImport("dll-tests.dll")]
private static extern int myInt ();

Finally, don't forget to put the dll in the directory that houses your C# executable (or someone on your path).

Now that that's solved, on to exporting CGAL classes (or datastructure or just functions, we'll see) to C#. Our research goal is to use CGAL classes quickly in prototyping ideas. We'll worry about efficiency later.

Posted by jones at December 26, 2006 07:56 AM

Comments

Post a comment