Update: Letzte Nacht habe ich entschieden, dass es zu viel Arbeit ist, um den Ordner zu ändern, in dem einige Berichte gespeichert werden. Meine Arbeitsumgebung besteht darin, den Ordner umzubenennen, den Batch-Job auszuführen, den ich erledigen muss, und dann den Ordnernamen wieder in den ursprünglichen Zustand zu ändern. Ich habe das Gefühl, ich könnte den Rest von heute und die ganze nächste Woche damit verbringen und noch nichts zu zeigen haben. Ich würde lieber die Hölle erwischen, wenn ich gegen meinen Chef vorgehe, als nicht in der Lage zu sein, unseren Kunden Rechnung zu stellen (was nur einmal im Jahr geschieht). Vielen Dank an alle, die geholfen haben, ich bin demütig von Ihrer Bereitschaft, einem anonymen Kerl über den Kopf zu helfen. Ich bin mir nicht sicher, wie ich diese Frage "ablegen" soll, aber ich gebe euch immer noch Requisiten, ich lese die FAQ und alle Kommentare während des Mittagessens. Danke.
Ich versuche eine c # -Anwendung zu debuggen, die mein Vorgänger erstellt hat. Er ist ein Programmierer, ich bin ein Systemadministrator, vielleicht bin ich hier falsch.
Wie auch immer, ich muss eine der Assemblies neu kompilieren und sie auf unserem Produktionsserver bereitstellen. Wenn ich es kompiliere, erhalte ich den Fehler:
Der Typ 'Mcrcsip.Web.McrcsipWebExceptionBase ist in einer Assembly definiert, auf die nicht verwiesen wird. Sie müssen einen Verweis auf die Assembly 'Mcrcsip.Web, Version = 2.0.3266.28977, Culture = neutral, PublicKeyToken = c3de6c6abcdf794b' hinzufügen.
Ich habe zufällig eine Kopie dieser Assembly, und wenn ich den Verweis auf die vorhandene Assembly lösche (2.0.0.0 mit einem anderen öffentlichen Schlüsseltoken) und einen Verweis auf die Assembly hinzufüge, nach der sie fragt, wenn ich kompiliere, I bekomme diese Fehlermeldung:
Der Typ 'Mcrcsip.Web.McrcsipWebExceptionBase ist in einer Baugruppe definiert, die ist nicht referenziert Sie müssen ein hinzufügen Verweis auf Assembly 'Mcrcsip.Web, Version = 2.0.0.0, Kultur = neutral, PublicKeyToken = 8bbdde85caf008d0 '.
Wenn ich auf Google nach diesem Fehler suche (natürlich generisch), bekomme ich eine Menge "Ergebnisse einer Assemblyreferenz hinzufügen ..." Ergebnisse.
Wie komme ich von diesem Karussell ab?
So sieht die Lösung aus:
http://amwa-test.internal.lan/ Referenzinkonsistenzen oder: wie ich gelernt habe, nicht mehr zu beunruhigen und ILDASM zu lieben
ähem, Husten Husten,
Problem
Nick,
Wenn Sie Ihren ursprünglichen Post erneut lesen, ist es offensichtlich, dass Sie ein Problem mit der DLL-Versionsinkonsistenz haben. Das heißt, mindestens ein Projekt in Ihrer Lösung hängt von der Mcrcsip.Web-Version X ab, und mindestens ein Projekt in Ihrer Lösung hängt von der Mcrcsip.Web-Version Y ab [oder noch schlimmer, hängt von einer Bibliothek ab, die von der Mcrcsip.Web-Version Y abhängt ]. Dies kann schwierig und mühsam zu finden sein.
Siehe Empfohlene Lösung , um zum Ende zu springen.
Wie
Diese Art von Inkonsistenz tritt auf, wenn
Im Gegensatz zu dem, was wir intuitiv erwarten, wird B nicht automatisch auf die Verwendung von C ver 2 aktualisiert, wenn wir A bauen. Sowohl A als auch B müssen auf die gleiche Bibliothek verweisen richtig bauen. Also muss entweder A zu C ver 1 passen, oder B muss neu aufgebaut werden und zu C ver 2 passen.
Nun kann dies bei jeder Projektkonfiguration passieren, weshalb es wichtig ist, Ihre Software zu versionieren [glauben Sie mir, dass dieses Problem schlimmer wird, wenn Sie die \ versionierung nicht richtig signieren] und gut mit Ihrem Team kommunizieren, wenn eine Abhängigkeitsaktualisierung auftritt / p>
Es ist auch wissenswert, dass es zwei Arten von Abhängigkeitsreferenzen gibt, hart und weich [tatsächlich sind sie die gleichen, das sind Links zu dlls, außer dass einer der Spezialfälle des anderen ist, und konzeptionell hilft es Unterscheide die zwei].
Harte Referenzen
Eine harte Referenz ist eine Abhängigkeit eines Projekts von einer statischen DLL. Das heißt, die Abhängigkeit wurde zu einem bestimmten Zeitpunkt erstellt und wird niemals aktualisiert, es sei denn, ihre physische Datei wird durch eine neue ersetzt. Harte Referenzen werden über den Dialog Referenzen hinzufügen zu einer Lösung hinzugefügt und fügen einen Verweis aus den Registerkarten .Net, COM oder Browse hinzu. Harte Referenzen werden typischerweise verwendet, um Abhängigkeiten zu Software hinzuzufügen, die außerhalb des Geltungsbereichs der aktuellen Lösung entwickelt wurde (dh Framework-, Third-Party- und andere First-Party-Produkte, die von anderen internen Teams entwickelt wurden). Harte Referenzen neigen auch dazu, veraltet zu werden, weil sie durch ihren eigenen Entwicklungsstrom gepflegt und aktualisiert werden.
Nehmen Sie das obige Szenario an
Angenommen, A und B befinden sich innerhalb der gleichen Lösung
Wenn A erstellt wird, erhalten Sie den von Ihnen beschriebenen Fehler. A erwartet ein Objekt von C v2, aber weil B eine harte Abhängigkeit von C v1 hat, wird C v1 zuerst in den Speicher geladen, und es tritt eine Kollision auf. A erwartet v2 und findet v1. Das ist dein Fehler.
Um diese Situation zu lösen, müssen Sie
Soft-Referenzen
Eine weiche Referenz ist eine Abhängigkeit eines Projekts von einem anderen Projekt innerhalb derselben Lösung. Das heißt, die Abhängigkeit wird jedes Mal neu erstellt, wenn die gesamte Lösung neu erstellt wird. Soft-Referenzen werden über den Dialog Referenzen hinzufügen zu einer Lösung hinzugefügt und eine Referenz von der Registerkarte Projekte hinzugefügt. Softreferenzen werden in der Regel verwendet, um Abhängigkeiten zu Software hinzuzufügen, die im Rahmen der aktuellen Lösung entwickelt wurde. Sie haben den primären Vorteil, Änderungen an die Konsumenten innerhalb derselben Lösung zu übertragen, wenn sie gemacht werden. Aufgrund dieser Tatsache können weiche Referenzen nicht veraltet sein.
[Dies ist ein spezieller Fall einer harten Referenz, Visual Studio fügt einen Verweis hinzu, der auf den Ausgabepfad des Zielprojekts verweist. Ich glaube, dass dieser Pfad auch aktualisiert wird, wenn das Zielprojekt seine Ausgabekonfiguration ändert - aber sehr praktische Eigenschaft, die Unterscheidung verdient]
Nehmen Sie das obige Szenario an
Angenommen, A und B befinden sich innerhalb der gleichen Lösung
Wenn A erstellt wird, erhalten Sie den von Ihnen beschriebenen Fehler. A erwartet ein Objekt von C v2, aber weil B eine harte Abhängigkeit von C v1 hat, wird C v1 zuerst in den Speicher geladen, und es tritt eine Kollision auf.A erwartet v2 und findet v1. Das ist dein Fehler.
Um es zu lösen,
Wie Sie sehen können, sind weiche Referenzen einfacher zu pflegen.
IL DASM [Intermediate Language Disasembling]
Nun, da Sie ein bisschen mehr über Referenzen und Projektwartung wissen, wie genau ermitteln Sie den Status Ihres Builds? Schließlich kann jemand Ihrer Projekte oder ihrer Abhängigkeiten inkonsistent sein.
Der einfache Weg besteht darin, das Build-Ausgabeverzeichnis zu öffnen und das Assembly-Manifest jeder einzelnen DLL zu prüfen, die von Ihrer Lösung erstellt wurde.
Um das Manifest einer Baugruppe zu überprüfen,
ildasm.exe
ildasm window Das ist langwierig und schmerzhaft, aber wenn Sie einen [nicht-trivialen] Dll-Inkonsistenzfehler entdecken, ist dies der einzige Weg, um ihn zu finden.
Empfohlene Lösung
Wenn bei diesem Schritt weiterhin Fehler auftreten, wissen Sie einen oder alle
teilt Ihre Abhängigkeit von Mcrcsip.Web und verweist auf die alte Version. Wenn dies der Fall ist, dann für jeden oben aufgeführten harten Verweis
ildasm
Stellen Sie sicher, dass Sie dies für jeden der drei oben genannten harten Referenzen tun. Sobald Sie herausgefunden haben, welche Teilmenge dieser drei auf die alte Version von Mcrcsip.Web verweist, können Sie dieses Projekt jetzt finden, seine Referenz aktualisieren, es neu erstellen und dann Ihr harte Referenz, Wiederaufbau und voila. Bob ist dein Onkel.
Puh.
Le fin
PS entschuldigt sich für Ausführlichkeit. Das ist kein sehr komplexes Problem, aber da Sie sicher sind, dass Sie mir zustimmen, beinhaltet es eine Menge Details.Ich hoffe wirklich, dass das hilft. Danke auch für Ihre Kooperation:)
PPS übrigens, ich folge aus Ihren Kommentaren, dass der ursprüngliche Entwickler überall harte Referenzen verwendete [dh sogar innerhalb derselben Lösung]. vielleicht hatte er seine Gründe, aber ich bin der Esel.
Wenn Sie mit der rechten Maustaste auf die Referenz klicken, gehen Sie zu den Eigenschaften, wofür ist "Spezifische Version" festgelegt? Stellen Sie sicher, dass es auf 'True' gesetzt ist und die gelistete Version in der Tat 2.0.x ist.
Überprüfen Sie auf der Eigenschaftenseite den Pfad. Möglicherweise haben Sie eine andere Version, die an anderer Stelle in Ihrem GAC registriert ist und Vorrang hat. Verwenden Sie "gacutil -l" in der Befehlszeile, um eine Liste aller registrierten Versionen dieser Assembly zu erhalten. Wenn Duplikate mit unterschiedlichen Schlüsseln angezeigt werden, benutze gacutil, um den nicht gewünschten zu erstellen.
Beobachten Sie die anderen Builds unter den Batch-Build-Optionen. Auf diese Weise können Sie priorisieren, welche Assembly zuerst erstellt werden soll. Anschließend sollten Abhängigkeiten ihre DLL in der richtigen Reihenfolge abrufen.
Tags und Links .net visual-studio reference gac circular-reference