1

I have several Unmanaged C++ written lib files which I need to link to Managed C++ dll.
Then I need to invoke functions of this Managed C++ from C# application.

First step is OK - Managed C++ dll is created, I can see with ildasm that it exports functions I need. However when I try to call this function from my C#-written test app it says:

An unhandled exception of type 'System.IO.FileLoadException' occurred in Unknown Module.
A procedure imported by {MyManagedCPP.dll} could not be loaded.

This message goes from VS2010.
I made simple experiment - removed dependencies from all lib files in Managed C++ dll and rebuild it.
With this change it is OK - app starts, I can call functions of Managed C++ dll from C# test app.

Is it not possible by design to call managed c++ functions when dll has static linkage with lib files? Technical restriction? Or there is some workaround?

Thanks

IgorStack
  • 799
  • 2
  • 6
  • 22
  • Have a look at System.Runtime.InteropServices. Specifically `DllImport["my.dll']`. Be careful with where you put your Dlls (they need to be in the working directory defined by your project, not necessarily next to the exe. – axon May 23 '13 at 01:34
  • No, I don't think I need DLLImport here. At the end I have managed dll and managed exe. But [DLLImport] "Indicates that the attributed method is exposed by an unmanaged dynamic-link library (DLL) as a static entry point." which is not my case. – IgorStack May 23 '13 at 15:50

1 Answers1

2

You no doubt have an implicit dependency on a native DLL. It isn't clear from the question what DLL that might be. It could be msvcrxx.dll for example, a runtime support library for native C++ code. Which would be rather bad, you don't want to mix CRT versions. Such a missing DLL otherwise prevents the C++/CLI assembly from getting loaded, producing the FileLoadException.

If you have no idea what that DLL might be then you could use SysInternals' ProcMon utility. The trace will show you the program searching for the DLL and not finding it. If it is msvcrxx.dll then be sure to rebuild the .lib files using the same compiler version you used to build the C++/CLI assembly. If it is something else then make sure you copy that DLL to the build directory.

Hans Passant
  • 922,412
  • 146
  • 1,693
  • 2,536
  • Sadly I cannot rebuild lib files - do not have sources. And I also know that they are built using VS2008 while I'm using VS2010. When I get error I see in Process explorer that managed dll is loaded and unmanaged dll (upon which managed one depends) is loaded too. Very much looks like this is an issue with different versions of compilers used. – IgorStack May 23 '13 at 16:08
  • Well, technically it is possible to survive the mismatch if the DLL was designed well. You will however need to have the correct version of msvcr90.dll present on your machine to solve the FileLoadException. – Hans Passant May 23 '13 at 16:24
  • Thank you, this led me to the answer. We have a C++/CLI library which links against some "real C++" libraries ;-) My colleague rebuilt the CLI library with VS2019 which did something weird with the linkage. I haven't had time to dig into it, but when I compare the two (his build versus my build) in Dependency Walker I can clearly see there are unresolved external functions in the native c++ libs we link with. – Jay Aug 17 '21 at 03:11