Assembly file locations
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… (source)
Examples of .Net application .dll files locations:
C:\Windows\Microsoft.NET\assembly\GAC_MSIL
C:\[application_directory]\bin\Debug
If the application is a web application hosted on Internet Information Service (IIS) .dll files might be located in the following directories:
C:\[IIS_webroot]\bin
When running IIS web applications from debug
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files\root
Loading order
.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. (source)
Listing loaded assemblies in Visual Studios
When debugging using Visual Studios you can see a list of loaded assemblies by navigating to the following menus:
Debug -> Windows -> Modules (source)
Another useful tool for analyzing assembly issues is FusionLog