1

Using CLI, I've wrapped a C# class library with a C++ DLL, so that the C# can be accessed from un-managed code. I've included the C# class library as a reference in the VisualStudio project for the C++ DLL, and I can run a little test program that calls methods from my C# classes through the C++ DLL. However, the test fails with the following message if the C# class library isn't in the same directory with the .exe that calls the wrapper.

Unhandled Exception: System.IO.FileNotFoundException: Could not load file or assembly 'MiniModel, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The system cannot find the file specified.

at MiniModelWrapper.MM_Interface.initialize(SByte* A_0)

at initialize(SByte* fn)

My Question:

Is there a VS setting I can use, or a piece of code I can introduce into the C++ wrapper, that will allow the wrapper to identify the location of the wrapped class library to a program that calls the wrapper? Would it be possible to make the wrapped libraries findable on the system path?

Background:

I'm working with a "framework" program that calls libraries from other programs using an API defined by functions declared in a C/C++ header file. Basically, we're trying to make a complex numerical model out of a collection of simpler sub-models coordinated by the framework program.

Some of the sub-models are in managed code, and I need to put wrappers around them so that the framework can call them. I found help here, and created a test around a very simple example -- I call it "MiniModel" -- that implements parts of the API in C# objects, then makes them accessible to a tester program through a "MiniModelWrapper" DLL.

The problem I'm having is similar to question 21742777 and as the solution there recommended, I used Process Monitor to get some understanding of where the program was looking for, but not finding, my library. I saw that the program looked through several directories listed in the path to find my wrapper library, but only in the directory where the test executable is located and in a (nonexistent) MiniModel subdirectory for the wrapped C# class library.

It's not going to be practical to put all the libraries that the framework calls in one directory. Having the wrappers point to the locations of the libraries they wrap seems like a practical solution. Can I do that?

Community
  • 1
  • 1
TomEvans
  • 96
  • 5
  • 1
    You want to create DLL Hell to make building your program a bit easier. It is invariably the end-user that's the victim and you're hoping that Microsoft added a feature in a place where the end-user *definitely* can't get out of Hell. They did not do that of course. – Hans Passant Mar 31 '19 at 10:47
  • Hello @HansPassant thanks for a number of very helpful suggestions, including the pointer to Process Monitor, definitely a step up from the other dependency checkers I've tried. Sadly, some level of DLL Hell is built into our project, since the framework and most of the sub-models are pre-existing code, each with its own chain of dependencies. The sub-models are created and maintained by completely independent entities, so I am very reluctant to mix up their components with those of the framework, which is a created and maintained by yet another independent entity. – TomEvans Apr 01 '19 at 20:35
  • The framework expects a sub-model to be represented by a DLL at a location given in a configuration file. I can point it to my wrapper library, but when the wrapper calls the managed-code library, the call fails unless I put the managed-code library (or a copy of it) inside the framework's 'bin' directory. THAT seems like a tangled mess that's sure to break when either the model or the framework gets an update. I begin to think that C++-CLI isn't a great way to do this, but I don't know of another way to access managed code from a native exe. Is there a better approach? – TomEvans Apr 01 '19 at 21:29

0 Answers0