Ich habe ein DLL-Projekt, das Microsoft.Practices.EnterpriseLibrary.Common.dll (= "die dll") von meinem Installationsverzeichnis der Microsoft Enterprise Library 3.1 verweist. Es hat einen öffentlichen Schlüssel, der mit "b03f" beginnt.
Ich habe ein anderes Projekt, das Miner.Geodatabase.dll Version 9.30.2.5168 verweist (Es zeigt 9.2.0.0 im GAC-Ordner). Die Miner-DLL hat einen öffentlichen Schlüssel, der mit "196b" beginnt.
Eine dritte DLL verweist auf die anderen beiden.Seltsam dll Verhalten (Frage Überholung)
Hier ist eine einfache VS2005-Lösung mit den oben genannten Projekten ELTest.rar-
1. Refel, verweist nur die DLL aus seinem Ordner lib.
2. RefGeodatabase, bezieht sich nur auf die Miner.Geodatabase.dll von der GAC.
3. RefBoth, verweist auf die anderen beiden Projekte.
Nach dem Übersetzen der ist/Debug-Ordner des Refel enthalten die "b03f" ("real") Version von die dll, während das ist/Debug von RefGeodatabase und RefBoth eine Version von die dll enthält mit ein öffentlicher Schlüssel, der mit "196b" beginnt - genau wie die Miner dll. Es scheint mir, sie haben die Enterprise-Bibliothek neu kompiliert (und möglicherweise etwas geändert).
Zur Laufzeit (In meiner wirklichen Lösung, nicht in dieser falschen Lösung), ruft meine "beide" Projekte das "EL" -Projekt auf, das die "b03f" -DLL benötigt, nicht finden kann und abstürzt.
Was soll ich tun? Wenn ich die Enterprise Library-DLLs im GAC registriere, werden sie möglicherweise zur Laufzeit gefunden. Gibt es eine andere Lösung, bei der ich die Entlib nicht auf meinem Zielcomputer installieren muss?
Welche Version (en) von Visual Studio verwenden Sie? Verwenden Sie Projektreferenzen oder Dateireferenzen? Wie sehen die HintPaths in den Projektdateien aus? Es ist völlig normal, dass DLLs so kopiert werden, wie Sie es beschreiben. –
Ich benutze VS2005 SP1 (passiert auch ohne SP installiert). Projekt A referenziert die EL-DLL als eine Datei (in einem lib-Ordner) und ** nicht ** von der GAC. Projekt B referenziert Miner.Geodatabase.dll (ver 9.30.2.5168) durch die GAC, und nach der Kompilierung erhält die seltsame EL-DLL damit. Ich verstehe nicht, woher diese DLL kommt. Aber Projekte, die sowohl auf A als auch auf B verweisen, erhalten diese seltsame DLL, und A schlägt zur Laufzeit fehl. –