1
votes

I am currently trying to basically expose a native C++ library, that I not have the code for, as a WebApi. To do that, I created a managed C++ wrapper library, that allows my web application to communicate with the native code.

So the dependencies of the project look something like this:

  • Web application (ASP.NET)
    • Managed C++ Wrapper
      • Native C++ Library (DLL)
        • Native Dependencies (DLLs)

My problem is now, that I always get the error message "Could not load file or assembly [ManagedWrapper.dll] or one of its dependencies. The specified module could not be found."

Since the managed wrapper library is in the same solution, it is listed as reference and even copied to the shadow copies, so I assume that the problem lies in the native dependencies. I am well aware that there are problems with loading native DLLs in ASP.NET as no shadow copies will be made of them and they can not be added to the GAC. I tried to tackle this problem by just adding them to my %PATH%, but the error still remains. Dependency walker did not show any additional dependencies and adding the native DLLs to system32/inetsvr fixed the problem, but this is obviously not the way this should be done.

So here my question: What could be the reason that the PATH variable is not working? (And is there maybe another way to get this to work?)

Using loadLibrary to load with an absolute path is not really a possible solution as I have no influence on the native C++ library and how it will load further dependencies.

1
FYI, same issue resolved here.Mansoor
@M.A As I wrote in my description, the solution from your link did not work here. Changing the PATH variable did not help and copying everything to system32/inetsvr is just not a good idea.Jerome Reinländer
Changing the path is what you did for your solution? I agree with your second point, you should not install your assemblies into protected OS folders.Mansoor
@M.A I moved the assemblies (or maybe the whole project? this is 2.5 years ago) to a different folder and then changed the PATH. Changing the PATH was necessary, but not sufficient alone. Again, my guess is with a problem with permissions.Jerome Reinländer

1 Answers

1
votes

I think I found my own a solution to my problem and hope this might help someone else as well:

My native DLLs where somewhere in my home folder. Moving them to a more accessible place, i.e. C:\temp\, and adding this folder to the path seemed to do the trick. My guess is, that this was a permission based problem, even though I added rights for IUSR for that folder in my home directory before.