Unmanaged DLLs fail to load on ASP.NET server

Question

This question relates to an ASP.NET website, originally developed in VS 2005 and now in VS 2008.

This website uses two unmanaged external DLLs which are not .NET and I do not have the source code to compile them and have to use them as is.

This website runs fine from within Visual Studio, locating and accessing these external DLLs correctly. However, when the website is published on a webserver (runnning IIS6 and ASP.NET 2.0) rather than the development PC it cannot locate and access these external DLLs, and I get the following error:

Unable to load DLL 'XYZ.dll': The specified module could not be found. (Exception from HRESULT: 0x8007007E)

The external DLLs are located in the bin directory of the website, along with the managed DLLs that wrap them and all the other DLLs for the website.

Searching this problem reveals that many other people seem to have the same problem accessing external non.NET DLLs from ASP.NET websites, but I haven't found a solution that works.

I have tried the following:

• Running DEPENDS to check the dependencies to establish that the first three are in System32 directory in the path, the last is in the .NET 2 framework.
• I put the two DLLs and their dependencies in System32 and rebooted the server, but website still couldn't load these external DLLs.
• Gave full rights to ASPNET, IIS_WPG and IUSR (for that server) to the website bin directory and rebooted, but website still couldn't load these external DLLs.
• Added the external DLLs as existing items to the projects and set their "Copy to Output" property to "Copy Always", and website still can't find the DLLs.
• Also set their "Build Action" property to "Embedded resource" and website still can't find the DLLs.

Any assistance with this problem would be greatly appreciated!

Answer 1

Run DEPENDS on XYZ.dll directly, in the location that you have deployed it to. If that doesn't reveal anything missing, use the fuslogvw tool in the platform SDK to trace loader errors. Also, the event logs sometimes contain information about failures to load DLLs.

Answer 2

Try putting the dlls in the \System32\Inetsrv directory. This is the working directory for IIS on Windows Server.

If this doesn't work try putting the dlls in the System32 directory and the dependency files in the Inetsrv directory.

Answer 3

Take a look with FileMon or ProcMon and filter on the names of the troublesome DLLs. This will show you what directories are scanned in search of the DLLs, and any permission issues you might have.

Answer 4

Always worth checking the path variable in your environment settings too.

Answer 5

Adding to Matt's answer, this is what finally worked for me for 64-bit server 2003 / IIS 6:

(1) make sure your dlls / asp.net are the same version (32 / 64 bit) (2) Put the unmanaged dlls in inetsrv dir (note that in 64 bit windows, this is under syswow64, even though the sys32/inetsrv directory is created) (3) Leave the managed dlls in /bin (4) Make sure both sets of dll's have read/execute permissions

Answer 6

This happens because the managed dlls get shadow copied to a temporary location under the .NET Framework directory. See http://msdn.microsoft.com/en-us/library/ms366723.aspx for details.

Unfortunately, the unmanaged dlls do NOT get copied and the ASP.NET process won't be able to find them when it needs to load them.

One easy solution is to put the unmanaged dlls in a directory that is in the system path (type "path" at the command line to see the path on your machine) so that they can be found by the ASP.NET process. The System32 directory is always in the path, so putting the unmanaged dlls there always works, but I would recommend adding some other folder to the path and then adding the dlls there to prevent polluting the System32 directory. One big drawback to this method is you have to rename the unmanaged dlls for every version of your application and you can quickly have your own dll hell.