How would i use a C++/CLI dll that wraps native code with multiple dependent libraries in C#?

Question

I am wondering how I would go about correctly setting up a C++/CLI library that wraps native c++ code that has several dependencies. I have tried both statically and dynamically linking the native library to its dependent libraries with no luck.

The Managed C++/CLI dll builds just fine and can be added as a reference to a C# project. However when I attempt to use any of the defined classes i receive either a BadImageFormatException or FileNotFoundException depending how i linked. I believe I need to specify the dependent libraries in the CLI library so it is loaded in the manifest but I am unsure of the process. Also because i know it will come up, I have verified that all of the libraries involved are built on the x86 architecture.

Any help would be great.

Answer 1

You should make the C++ dll in release mode and use extern "C" for public static things.

Answer 2

I have gotten that error when the dependent libraries were not in the path. The wrapper library is found because of the reference, but the reference does not also take care of the dependent libraries. Try placing them explicitly where the program is executing.

Answer 3

I figured out the problem and everything is working correctly now. It was a combination of several incorrect things all happening together.

If anyone has the same issue, I resolved it by setting up the following:

1) The Boost libraries that were referenced (specifically boost_thread) needed to be compiled with BOOST_THREAD_USE_DLL preprocessor (other boost libraries may need BOOST_ALL_DYN_LINK to just dynamically link everything). This is apparently a common issue.

2) I verified that all dependencies were in system Path (like R Ubben reiterated)

3) I used the DependencyWalker (depends.exe from sourceforge) to analyze my compiled managed DLL. It turned out that the libpq.lib library being used actually referenced additional DLLs that were not included in the lib folder but in the bin folder. So that need to be added to the Path.

4) Part of my wrapper was using the #include header for lists. This forced my library to link against 2.0 framework dependent libraries. This was not compatible with my 4.0 client targeted C# application. This was only made known by parsing through the Warnings from compiling (previously hidden due to C++ generating too many..foolish i know). However this was resulting in a System.BadImageFormateException being thrown despite everything targeting the same x86 architecture.

Hope that helps anyone else who has the same problem. The BadImageFormateException and FileNotFoundException were entirly too vague and unhelpful.