ASP.NET 4 App dll is shadow copied but bin dll is loaded instead

Having a very odd issue with a large asp.net 4 application. IIS will sometimes load modules not from the shadow copy location but instead the bin directory where the dlls are originally sourced from.

Does anyone know how the IIS module loading works and whether this is normal behaviour or a bug?

Problems this is causing us

• In dev; the respective dlls get locked in the bin folder meaning that msbuild cannot replace it on build.
• this is causing us a particularly nasty (and difficult to find) issue (which we are working around with a hack) where we get TypeMismatchException in nhibernate queryovers

Notes

• ASP.NET 4 application running on Win7 & WinServer2008R2, IIS 7.5, multiple projects using MVC3, MVC4, WebForms, WebApi
• Module information sourced by attaching VS debugger and inspecting loaded modules
• If I IISRESET and clear the temp asp.net files folder then spool up the application then the dlls are all copied to the shadow copy location and are then loaded from there. If I then IISRESET again and spool up the application the modules are loaded from the bin location instead of the shadow copy location
• This only affects project dependencies of the web project the entry point is always loaded from the shadow copy location. IE Proj.Web will load from shadow copy location, a project dependency of that Proj.BusinessLogic & Proj.DataAccess will load from the bin folder, external dependencies (automapper, glimpse, etc) will load from the shadow copy location.
• We are not overriding any app pool or app domain configuration in either code, web.config or IIS config (default settings).
• Can't find anywhere that module loading or app startup is verbosely logged to.

Discovered the root cause of this issue a few weeks ago, posting now to hopefully help anyone who suffers from anything similar.

After a couple aha moments from a few of our devs we discovered that this was self-inflicted by the way that we were scanning dlls for nhibernate configurations.

When we were explicitly loading the dlls from code we were misusing the Assembly helper methods. Instead of using Assembly.LoadFrom(assemblyPath) we were using Assembly.LoadFile(assemblyPath). There are a bunch of differences between these methods, relevant here is that LoadFile() loads the specified file whereas LoadFrom() will apply logic for finding the assembly from other locations such as temp, cache or GAC. See this question for more details of the differences.

Anyway, after changing this single line of code, all of our problems disappeared.