How to debug .dll assembly errors

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
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files\root (when running IIS web applications from debug)

Prioritize loading local assemblies over GAC assemblies ?

.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 during debug 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