When a .Net application is started the .Net framework loads assemblies (.dll files) into the application domain at run-time. The .Net framework will attempt these .dll files from a predefined order starting from the Global Assembly Cache (GAC ) followed by the application’s execution directory, etc…
Examples of .Net application .dll files locations:
If the application is a web application hosted on Internet Information Service (IIS) .dll files might be located in the following directories:
When running IIS web applications from debug
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files\root
.Net Framework prioritizes loading assemblies from the Global Assembly Cache (GAC ). This becomes a problem when you want to debug a local assembly file that also lives in the GAC. As long as the assembly files versions in the GAC is identical to the local assembly file, local assemblies will not be loaded.
Workaround to the problem, remove signing from the local assembly (i.e.: do not sign the local assembly), the application will use the unsigned local assembly instead of the one in the GAC. This is because .Net Framework skips assembly version checking for assemblies without strong names (unsigned assemblies) and skips the run-time check in the GAC for assemblies without strong names.
When debugging using Visual Studios you can see a list of loaded assemblies by navigating to the following menus:
Debug -> Windows -> Modules
Another useful tool for analyzing assembly issues is FusionLog