There's a common misconception out there among .NET developers that when the runtime loads an assembly, the CLR first looks in the application's private bin directory. This is not true. I could go into a huge mess of details about this, but maybe some other day. For now, what you need to know is that before the CLR can actually load an assembly, it must be able to find the assembly. To do this, the CLR makes use of this thing called the Assembly Resolver, whose sole responsibility is to find out where the physical assembly is located, and then pass that info on to the assembly binding mechanism, after which the application can finally use the types defined in the assembly.
So where does the Assembly Resolver look for assemblies, and in what order does it perform its searches? Glad you asked:
1. The GAC, for a native image of the assembly
2. The GAC, for a non-native image of the assembly
3. In the CodeBase location, if one was defined
4. In the AppBase directory, otherwise known as the private bin directory
5. In any subdirectories as specified in the probing paths, if defined in the application config file
As you can see, the applications's private bin directory is the *4th* location the CLR looks for an assembly, not the 1st location. Assemblies in the GAC are system-wide assemblies and therefore take precedence over everything else (assuming versions and other criteria match, but that's a whole other issue).
And as a reminder, if you ever run into issues loading assemblies, you can always use the Assembly Binding Log Viewer (fuslogvw.exe) to see what locations are being searched as the CLR tries to load the assemblies for your application. For details on setting up and running fuslogvw.exe, see this post by Javier Lozano.
BTW, even the best people make this common mistake. While I was at the HDC, I took in Andrew Troelsen's talk on building extensible apps (reflection, attributes, etc). He gave an excellent talk, but he did say that the AppBase location was the first place the CLR looked to load assemblies.
Print | posted on Sunday, October 16, 2005 12:14 AM