I have been working through a number of very ‘odd’ issues with some DLL versions, Policy Files, and items in the GAC and for the life of me I haven’t been able to find a solid answer as to how/why the .NET framework picks the assemblies that it does, when binding project references.
First of all to give a bit of history about what we have, we have two library DLL files with the following information
ApplicationAssembly.dll - .NET 1.1 code - .dll Version 01.01.00.1234 ApplicationAssembly.dll - .NET 1.1 code - .dll Version 01.01.00.1244 ApplicationAssembly.dll - .NET 2.0 code - .dll Version 02.00.00.1111 Each of these assemblies are loaded into the GAC, and the 1.1 and 2.0 versions each have a policy file specifying the most current version for loading.
We have a project that references the 1.1.00.1234 version of the ApplicationAssembly.dll file, however, the project was moved and the hint path is no longer valid. However, the reference is not dead, but it is showing to the 02.00.00.1111 version and not the intended 1.1 version of the assembly.
How is this process determined, and why did it jump right away to the 2.0 framework? If we specify that it is a ‘Specific Version’ reference, even with an incorrect hintpath it will find the proper DLL, but due to future risk of breaking things we cannot leave that setting turned on.
I guess the question is Why does this happen? And how does .NET determine where to go for the assembly?
The rules Fusion (the managed dll loading functionality in .Net) uses to locate dlls is quite extensive (due to the Gac/strong names/custom loading hooks to name but a few).
The official rules are dealt with in broad strokes here Since your library is strong named the more complex rules will apply