I struggled for a while with a bizarre .NET assembly problem last night – I was getting a runtime exception when trying to access a new type in a strong-named library from a strong-named executable. Compilation was succeeding, and the assemblies were in the same directory, so I couldn't figure it out.

My first instinct was that the assembly must be in the global assembly cache (GAC), since I remembered that the GAC is checked even before assemblies in the same directory when everything is strong-named. But it wasn't there. So I finally ended up using the Assembly Binding Log Viewer (Fuslogvw.exe) for the first time. The executable wasn't having any trouble locating the library, so I had to set the ForceLog registry value to get more information. As it turns out, it was getting the assembly from the “download cache.” I didn't really know much about the download cache, presuming that it would never affect local assemblies, but somehow, though I haven't figured it out yet, I managed to get my assembly into the download cache, and the .NET Framework was using the old assembly without the new type from there.

Of course, I could have avoided this trouble altogether if I'd made sure that I was advancing the assembly version with every build. I've read arguments for and against the asterisk-syntax for assembly versions (e.g., “1.0.*”) – this seems like a pretty good argument for...