VB.NET web application path issue

[Cerebus451]

Hopefully I can describe this correctly. I have a thin VB.NET web application that is basically just implementing a SOAP service around another .NET manage DLL built in C++. The problem is the managed .NET library has a dependency on a third party DLL that is unmanaged code.

When I try to test the web site/SOAP service, I get an error that the managed DLL (or one of its dependencies) cannot be loaded. I put the unmanaged DLL in the same folder as the managed DLL (which works for a normal VB app), but still no dice. If I drop the unmanaged DLL into c:\windows\system32, it all works, but this is something that will get delivered to clients, so that is not a workable solution.

I once read somewhere that there were issues with putting the unmanaged DLLs in the same folder as the managed DLL, and that all you had to do was move the unmanaged DLL to another folder and figure out some way to modify the path. My Google-fu only reveals solutions that involve either copying the DLL to the system directory or modifying the system path on the machine, neither of which is a workable solution. I can't find any information on modifying the DLL search path for a web application and figured I would post here in the hopes that some other poor soul has run into this and knows the solution.

 

[Bulldog13]

Add it to the GAC maybe ?

Or Regsvr32 it ?

Shot in the dark.

 

[Markbnj]

It's probably just that the version of the C/++ runtimes that the native DLL uses isn't present on your system. We ran into this just the other day, in almost the exact same circumstances. The native team had built their DLL with the 10.0 version of the MSVC runtime and the only ones of us who had it were those who installed C++ when they installed VS2010.

Use depends.exe to find out what libraries the native DLL requires, and make sure they are all present on your system and on the path when LoadLibrary is called.

Edit: missed the point that it works in system32. That's pretty strange, but anyway, I think depends.exe is still your best bet.

 

[KB]

"If I drop the unmanaged DLL into cwindows\system32, it all works, but this is something that will get delivered to clients, so that is not a workable solution."

Why are none of these workable solutions? Because the client doesn't want you to do them? Or because you aren't building an install package to deliver the files?
Obviously an install pacage could easily do these steps; however, both of them can also be automated in the app to the point where the client wouldn't even know you were doing them.

You can change the user or processes (not the machines) PATH variable using:

System.Environment.SetEnvironmentVariable("PATH", Yourpathhere, EnvironmentVariableTarget.Process)

use EnvironmentVariableTarget.User for user

you could possibly put the code in the global.asax files on application startup.

You could also try to copy the dll to system32 on application startup, again in global.asax. For these in-app changes you may need to lazy load the managed dll so it doesn't attempt to load the unmanaged ddl on startup.