Unmanaged DLLs fail to load on ASP.NET server

Collectives™ on Stack Overflow

Find centralized, trusted content and collaborate around the technologies you use most.

Learn more about Collectives

Teams

Q&A for work

Connect and share knowledge within a single location that is structured and easy to search.

Learn more about Teams

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!

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.

This is a better answer than the accepted answer because it explains why you'd want to do this. – Tom W Mar 21, 2015 at 9:40 From my experience, when I create a new directory, add it to PATH and put the DLL in there, it is found just fine when running local. However, this is not the case when hosted on IIS - the DLL is only found when I have it in /Windows/System32. Does IIS perhaps use a different variable for the path in some cases? – Jake Wood Jun 23, 2016 at 21:13

As an alternate to putting the dll in a folder that is already in the path (like system32) you can change the path value in your process by using the following code

System.Environment.SetEnvironmentVariable("Path", searchPath + ";" + oldPath)
Then when LoadLibrary tries to find the unmanaged DLL it will also scan searchPath.  This may be preferable to making a mess in System32 or other folders.
                Only works with PInvoke. if using a mixed mode assembly, the DLLs are linked (and fail) before any code runs.
– Nick Whaley
                Sep 25, 2014 at 21:38
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.
                Here's an answer without needing to pollute the system32 folder: stackoverflow.com/a/4598747/92756
– Felix Alcala
                Jul 1, 2013 at 13:17
                instead, you can disable ShadowCopying by adding <hostingEnvironment shadowCopyBinAssemblies="false"/> on the web.config, provided you are not modifying binaries in the live application.
– Amit
                Jun 29, 2015 at 22:47
                I got burned by making a copy of my DLL and putting it in System32 because I forgot about it, and then I had the wrong version of Microsoft.Azure.Documents.ServiceInterop.dll getting loaded for my project which resulted in weird local queryRanges[0].isMinInclusive errors when trying to connect to the db.  My fix ended up being to make sure my local IIS DefaultAppPool Identity was my local user.  See also: github.com/Azure/azure-documentdb-dotnet/issues/267
– Zachstronaut
                Jun 12, 2017 at 22:03
Adding to Matt's answer, this is what finally worked for me for 64-bit server 2003 / IIS 6:
make sure your dlls / asp.net are the same version (32 / 64 bit)
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)
Leave the managed dlls in /bin
Make sure both sets of dll's have read/execute permissions 
                I found this to be too tedious and  won't allow for differing versions of dlls. We resolved this by using symbolic links.
– Ristogod
                May 12, 2022 at 20:58
                ProcMon is extremely useful in figuring out dependencies and what a certain DLL will not load.
– Oliver
                May 26, 2016 at 11:43
                I wouldn't recommend this approach for apps or libraries that might be run or used in PAAS hosts (like Azure Websites).
– yzorg
                Apr 17, 2015 at 14:32
                why wouldn't you recommend this? I am considering to use this approach for Azure Functions app where I need to run native executable from the managed assembly.
– Štěpán Beneš
                Jun 12, 2017 at 19:06
                Azure functions didn't exist when I wrote it.  Azure Functions are so small and targeted, if you get it working then go for it!
– yzorg
                Jun 13, 2017 at 12:53
                @Ristogod: The answer is four years old and you're downvoting me because I didn't keep track to make sure the link was active? Tough crowd.
– annakata
                Nov 14, 2012 at 20:58
                @annakata You're supposed to extract the important information from the link so when it goes down this answer is still valid ;)
– Drax
                Jun 24, 2015 at 8:35
                @annakata The answer is clear enough for me but probably not that self explanatory for all interested users :)
– Drax
                Jul 2, 2015 at 7:56
I have come across the same issue. And I tried all above options, copying to system32, inetpub, setting path environment, etc nothing worked. 
This issue is finally resolved by copying unmanaged dll to the bin directory of web application or web service. 
Аfter struggling all day over this problem and finally I found a solution which suits me. It's just a test, but the method is working.
namespace TestDetNet
    static class NativeMethods
        [DllImport("kernel32.dll")]
        public static extern IntPtr LoadLibrary(string dllToLoad);
        [DllImport("kernel32.dll")]
        public static extern IntPtr GetProcAddress(IntPtr hModule, string procedureName);
        [DllImport("kernel32.dll")]
        public static extern bool FreeLibrary(IntPtr hModule);
    public partial class _Default : System.Web.UI.Page
        [UnmanagedFunctionPointer(CallingConvention.StdCall)]
        private delegate int GetRandom();
        protected System.Web.UI.WebControls.Label Label1;
        protected void Page_Load(object sender, EventArgs e)
            Label1.Text = "Hell'ou";
            Label1.Font.Italic = true;
        protected void Button1_Click(object sender, EventArgs e)
            if (File.Exists(System.Web.HttpContext.Current.Server.MapPath("html/bin")+"\\DelphiLibrary.dll")) {
                IntPtr pDll = NativeMethods.LoadLibrary(System.Web.HttpContext.Current.Server.MapPath("html/bin")+"\\DelphiLibrary.dll");
                if (pDll == IntPtr.Zero) { Label1.Text =  "pDll is zero"; }
                  IntPtr pAddressOfFunctionToCall = NativeMethods.GetProcAddress(pDll, "GetRandom");
                  if (pAddressOfFunctionToCall == IntPtr.Zero) { Label1.Text += "IntPtr is zero";   }
                    GetRandom _getRandom = (GetRandom)Marshal.GetDelegateForFunctionPointer(pAddressOfFunctionToCall,typeof(GetRandom));
                    int theResult = _getRandom();
                    bool result = NativeMethods.FreeLibrary(pDll);
                    Label1.Text = theResult.ToString();
(customise /bin/x64 and bin/dll/x64 folders as needed)
String _path = String.Concat(System.Environment.GetEnvironmentVariable("PATH")
                , System.Web.Hosting.HostingEnvironment.MapPath("~/bin/x64")
                , System.Web.Hosting.HostingEnvironment.MapPath("~/bin/dll/x64")
            System.Environment.SetEnvironmentVariable("PATH", _path, EnvironmentVariableTarget.Process);
        Thanks for contributing an answer to Stack Overflow!
Please be sure to answer the question. Provide details and share your research!
But avoid …
Asking for help, clarification, or responding to other answers.
Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
				VS 2005, website project: managed C++ assemblies require dependencies in path, not bin dir?
                See more linked questions