I have a dll project that references Microsoft.Practices.EnterpriseLibrary.Common.dll (=”the dll“) from my install dir of the Microsoft Enterprise Library 3.1. It has a public key that starts with “b03f”.
I have another project that references Miner.Geodatabase.dll version 9.30.2.5168 (It shows 9.2.0.0 in the GAC folder). The Miner dll has a public key starting with “196b”.
A third dll references the other two.
Here’s a simple vs2005 solution with the above projects
ELTest.rar –
1. RefEL, just references the dll from its lib folder.
2. RefGeodatabse, just references the Miner.Geodatabase.dll from the GAC.
3. RefBoth, references the other two projects.
After compilation, the bin/debug folder of the RefEL contains the “b03f” (“real”) version of the dll, while the bin/debug of RefGeodatabase and RefBoth contain a version of the dll with a public key starting with “196b” – same as the Miner dll. It seems to me they have recompiled the enterprise library (and possibly changed something).
At runtime (In my real solution, not in this bogus solution), my “both” projects calls the “EL” project, that needs the “b03f” dll, can’t find it, and crashes.
What am I supposed to do? Maybe if I register the Enterprise Library dlls in the GAC they will be found at runtime. Is there a different solution that does not require me to install the entlib on my target computer?
Well, I’ve decided to register the normal (“b03f”) version of the enterprise library in my GAC (and also on the production computers). I’ve used this link to register all the dlls at once. worked like a charm.
Now, my RefEL project references the GAC version of the dll, and even though the RefGeodatabase has Miner.Geodatabase.dll, which references the “196b” version from the GAC with CopyLocal=true, at runtime my project finds the “b03f” version in the GAC and doesn’t crash.