Menu
I have a C++ DLL (no code) that I want to expose to .NET applications.
After pondering all the options I have/know of/could find (COM, P/Invoke, SWIG, etc.), I'm writing a .NET Class Library (in C++/CLI). Now the resulting DLL (class library) requires the original DLL and its dependencies, too. My problem lies in automagically keeping track of such things, so that applications that use the wrapper don't have to keep track of the other (native) DLLs (especially if the original DLL(s) develop a new dependancy).
To be more precise (and have something concrete to discuss), I'm trying to wrap cmr, so I write MR, the class library (which depends on cmr, naturally). cmr depends on PNL, OpenCV, and others. When I tried adding a reference to MR in a (C#) project, Visual Studio (2005 SP1) just copied MR.DLL, leaving all the dependencies behind, and then complaining (throwing a FileNotFoundException about missing modules). Manually copying cmr, PNL, etc. to the bin directory fixed the problem.
Without further ado, my question is this: Is there a way for .NET apps to only add a reference to one DLL, and everything just works?
I've been scouring through Google and SO, to no avail...
EDIT: mergebin seems the closest to what I'm looking for, but it can only merge a .NET DLL with one native DLL. Too bad one can't merge native DLLs.
377
Load your DLL into it, right click, and chose 'Analyze' - you'll then see a "Depends On" item which will show you all the other dll's (and methods inside those dll's) that it needs.
When you use depends.exe, be aware that a DLL might have a dependency on another DLL or on a specific version of a DLL. You can use depends.exe on either the development computer or on a target computer. On the development computer, depends.exe reports the DLLs that are required to support an application.
Native DLL's are usually DLL's containing raw processor directly-executable code (such as that found in the Win32 API's) as opposed to, for example, managed (MSIL) which contain code that is consumed and JIT compiled to native processor instructions by a runtime such as the . NET CLR. In .
You might take a look at mergebin, a tool that allows you to combine unmanaged and managed DLLs into one assembly. System.Data.SQLite uses this approach.
132
I'm currently having a very similar problem.
One big step too meet my goal was to copy the Native .DLL into the output directory by a pre-built step in the C++/CLI project and add the linker option
/ASSEMBLYLINKRESOURCE:"$(OutDir)\Native.dll"
This writes into the resulting assembly that there is a file "Native.dll" that belongs to the assembly. Now all projects referencing that project/assembly will also copy the Native.dll around! (It should also go into the GAC if you put you're assembly there - I didn't check that).
Okay, you still have to add all depending native.dll's. I also don't know if the native DLL is found on run-time if you load the assembly via Assembly.LoadFrom() from a very different path (this is something I have to solve for my problem because our C++/CLI wrapper assembly is needed by the Visual Studio designer).
I hope this helps you a bit for you're problem.
EDIT:
Further investigations showed that the Wrapper .DLL always finds the native .DLL...that's the good thing. The bad thing is that the Visual Studio Designer copies the needed assemblies to a temporary directory (somewhere inside the user directory) when you open a form. When it copies the assemblies it ignores the linked resources and by this the native .DLL!
25
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
