By default, ASP.NET uses shadow copying, which “enables assemblies that are used in an application domain to be updated without unloading the application domain.” Basically, it copies your assemblies to a temporary folder and runs your web app from there to avoid locking the assemblies, which would prevent you from updating those assemblies.
This works great for managed DLLs, but not very well for native DLLs. ASP.NET doesn’t copy the native DLLs, so the web app fails with an error that doesn’t even make it obvious that a native DLL is missing or which one it is.
The simplest solution I’ve found is to turn off shadow copying, which causes the DLLs to be loaded directly from the
bin directory. This is the strategy now being used in production by Biblia.com. Just add a
<hostingEnvironment> element to your
<configuration> ... <system.web> ... <hostingEnvironment shadowCopyBinAssemblies="false" />
This also works for local development, but you may find that you need to restart the app pool in order to rebuild the app. Biblia has a pre-build step that runs
appcmd stop apppool and a post-build step that runs
appcmd start apppool with the corresponding
Alternatively you could consider removing
<hostingEnvironment> from your local
web.config and putting your
bin folder in the
PATH system environment variable, but that will be problematic if you have multiple web apps that depend on different builds of the native DLLs.
Posted by Ed Ball on May 14, 2013