Forcing the system to ignore the GAC?

I'm tracking down an elusive bug through a lot of libraries, and to help with debugging I've added lots of trace statements. Most of the time, when I take great care to put all of the files in a specific place and build in the right order, everything works out OK.

But sometimes things don't play nice. The most crucial DLL happens to be our product's Common dll; the release version is installed in the GAC. My understanding and assumption was that if I placed a debug DLL in the same directory as the application, it would bind to the local copy instead of the one in the GAC. Instead, I'm loading the GAC every time.

It's not possible to uninstall the version in the GAC. There are other components independent of my project that must be functional, and they rely on this dll as well.

I know there's probably some mucking about with a config file I should do, but doing a little research is not proving successful. How do I make the application prefer the local DLL over the one in the GAC?

As you found out, the GAC version is ALWAYS used. The CLR only starts probing after a GAC version is not found. To circumvent this, you can redirect requests from the GAC version to the local version with the bindingRedirect (http://msdn2.microsoft.com/en-us/library/eftw1fys.aspx) config element.

I'll look in to using that one after lunch; I think part of the problem is I'm not making a new version number for the assembly.

So far I'm finding that if I am REALLY careful about how I build it all works out. The debugger still claims it's using the GAC version, but all of my debug statements are getting printed so who knows what's going on there.

Ah! I found this (http://msdn2.microsoft.com/en-us/library/yx7xezcf(vs.71).aspx) on MSDN a while ago, and had to re-find it :) It should help with understanding how the CLR binds to assemblies.

Yeah I was reading that and at first thought there HAD to be a way to override the GAC, but then I thought about it some more and came up with some scenarios where you definitely wouldn't want that to happen and I guess it's a fair tradeoff.

Supposedly the build process is putting the correct DLL in the GAC, but it still goes bonkers every now and then.