Ich entwickle derzeit eine .NET-Anwendung, die aus 20 Projekten besteht. Einige dieser Projekte werden mit .NET 3.5 kompiliert, andere sind noch .NET 2.0-Projekte (bisher kein Problem).
Das Problem ist, dass ich immer die folgende Warnung bekomme, wenn ich eine externe Komponente einbinde:
"Found conflicts between different versions of the same dependent assembly".
Was genau bedeutet diese Warnung und gibt es möglicherweise die Möglichkeit, diese Warnung auszuschließen (wie die Verwendung von #pragma disable in den Quellcodedateien)?
Antworten:
Diese Warnung bedeutet, dass zwei Projekte auf dieselbe Assembly verweisen (z. B.
System.Windows.Forms
), die beiden Projekte jedoch unterschiedliche Versionen erfordern. Sie haben einige Möglichkeiten:Kompilieren Sie alle Projekte neu, um dieselben Versionen zu verwenden (z. B. alle auf .Net 3.5 verschieben). Dies ist die bevorzugte Option, da der gesamte Code mit den Versionen der Abhängigkeiten ausgeführt wird, mit denen sie kompiliert wurden.
Fügen Sie eine verbindliche Weiterleitung hinzu . Dadurch wird die Warnung unterdrückt. Ihre .Net 2.0-Projekte werden jedoch (zur Laufzeit) an die .Net 3.5-Versionen abhängiger Assemblys wie z
System.Windows.Forms
. Sie können schnell eine Bindungsumleitung hinzufügen, indem Sie in Visual Studio auf Fehler doppelklicken.Verwenden Sie
CopyLocal=true
. Ich bin nicht sicher, ob dies die Warnung unterdrücken wird. Wie bei Option 2 oben bedeutet dies, dass alle Projekte die .NET 3.5-Version von System.Windows.Forms verwenden.Hier sind einige Möglichkeiten, um die beleidigenden Referenzen zu identifizieren:
quelle
Grundsätzlich geschieht dies, wenn für die Assemblys, auf die Sie verweisen, "Local kopieren" auf "True" gesetzt ist. Dies bedeutet, dass eine Kopie der DLL zusammen mit Ihrer Exe im Ordner "bin" abgelegt wird.
Da Visual Studio auch alle Abhängigkeiten einer Assembly kopiert, auf die verwiesen wird, können zwei verschiedene Builds derselben Assembly verwendet werden, auf die verwiesen wird. Dies ist wahrscheinlicher, wenn sich Ihre Projekte in separaten Lösungen befinden und daher separat kompiliert werden können.
Ich habe es umgangen, indem ich Copy Local für Referenzen in Assembly-Projekten auf False gesetzt habe. Tun Sie dies nur für ausführbare Dateien / Webanwendungen, bei denen Sie die Assembly benötigen, damit das fertige Produkt ausgeführt werden kann.
Hoffe das macht Sinn!
quelle
Ich wollte Pauloyas Lösung veröffentlichen, die sie in den obigen Kommentaren angegeben haben. Ich glaube, es ist die beste Lösung, um die beleidigenden Referenzen zu finden.
Wenn Sie beispielsweise das Ausgabefeld nach "Konflikt" durchsuchen, finden Sie möglicherweise Folgendes:
Wie Sie sehen, besteht ein Konflikt zwischen den EF-Versionen 5 und 6.
quelle
update-package [your package name] -version 6.0.0 -reinstall
meiner Antwort hier ähnelt. Stackoverflow.com/questions/22685530/…Ich hatte das gleiche Problem mit einem meiner Projekte, aber keines der oben genannten Probleme half, die Warnung zu lösen. Ich habe die detaillierte Build-Protokolldatei überprüft, mit AsmSpy überprüft, ob ich für jedes Projekt in der betroffenen Lösung die richtigen Versionen verwendet habe. Ich habe die tatsächlichen Einträge in jeder Projektdatei doppelt überprüft - nichts hat geholfen.
Schließlich stellte sich heraus, dass das Problem eine verschachtelte Abhängigkeit von einer der Referenzen war, die ich in einem Projekt hatte. Diese Referenz (A) erforderte wiederum eine andere Version von (B), auf die direkt aus allen anderen Projekten in meiner Lösung verwiesen wurde. Das Aktualisieren der Referenz im referenzierten Projekt hat das Problem behoben.
Ich hoffe, das Obige zeigt, was ich meine. Ich habe ein paar Stunden gebraucht, um es herauszufinden. Hoffentlich wird auch jemand anderes davon profitieren.
quelle
Wenn Sie in Visual Studio mit der rechten Maustaste auf die Lösung klicken und Nuget-Pakete verwalten, wird eine Registerkarte "Konsolidieren" angezeigt , auf der alle Pakete auf dieselbe Version festgelegt werden.
quelle
Ich hatte gerade diese Warnmeldung und bereinigte die Lösung und kompilierte sie neu (Build -> Clean Solution) und sie verschwand.
quelle
Ich hatte das gleiche Problem und habe es behoben, indem ich Folgendes in web.config geändert habe.
Es ist mir passiert, weil ich die Anwendung mit Newtonsoft.Json 4.0 ausführe
Von:
Zu:
quelle
Ich habe eine andere Möglichkeit, dies zu tun, wenn Sie Nuget zum Verwalten Ihrer Abhängigkeiten verwenden. Ich habe festgestellt, dass VS und Nuget manchmal nicht übereinstimmen und Nuget nicht erkennen kann, dass Ihre Projekte nicht synchron sind. Die packages.config sagt eine Sache aus, aber der in Referenzen - Eigenschaften gezeigte Pfad zeigt etwas anderes an.
Wenn Sie bereit sind, Ihre Abhängigkeiten zu aktualisieren, gehen Sie wie folgt vor:
Klicken Sie im Projektmappen-Explorer mit der rechten Maustaste auf das Projekt und klicken Sie auf "Nuget-Pakete verwalten".
Wählen Sie im linken Bereich die Registerkarte "Installierte Pakete". Notieren Sie Ihre installierten Pakete. Wenn Sie viel haben, möchten Sie möglicherweise zuerst Ihre packages.config auf Ihren Desktop kopieren, damit Sie sie bei Google überprüfen können, um festzustellen, welche Nuget-Pakete installiert sind
Deinstallieren Sie Ihre Pakete. Es ist in Ordnung, wir werden sie gleich wieder hinzufügen.
Installieren Sie sofort die benötigten Pakete. Nuget stellt Ihnen nicht nur die neueste Version zur Verfügung, sondern ändert auch Ihre Referenzen und fügt die verbindlichen Weiterleitungen für Sie hinzu.
Tun Sie dies für alle Ihre Projekte.
Führen Sie auf Lösungsebene ein Clean and Rebuild durch.
Möglicherweise möchten Sie mit den niedrigeren Projekten beginnen und sich auf die höheren Projekte vorarbeiten und jedes Projekt im Laufe der Zeit neu erstellen.
Wenn Sie Ihre Abhängigkeiten nicht aktualisieren möchten, können Sie die Paketmanagerkonsole und die Syntax Update-Package -ProjectName [yourProjectName] [packageName] -Version [versionNumber] verwenden.
quelle
Dies hängt tatsächlich von Ihrer externen Komponente ab. Wenn Sie in einer .NET-Anwendung auf eine externe Komponente verweisen, wird eine GUID generiert, um diese Komponente zu identifizieren. Dieser Fehler tritt auf, wenn die externe Komponente, auf die von einem Ihrer Projekte verwiesen wird, denselben Namen und eine andere Version als eine andere solche Komponente in einer anderen Assembly hat.
Dies passiert manchmal, wenn Sie "Durchsuchen" verwenden, um Referenzen zu finden und die falsche Version der Assembly hinzuzufügen, oder wenn Sie eine andere Version der Komponente in Ihrem Code-Repository haben als die, die Sie auf dem lokalen Computer installiert haben.
Versuchen Sie herauszufinden, bei welchen Projekten diese Konflikte auftreten, entfernen Sie die Komponenten aus der Referenzliste und fügen Sie sie erneut hinzu, um sicherzustellen, dass Sie auf dieselbe Datei verweisen.
quelle
=> Überprüfen Sie, ob eine Instanz der Anwendung teilweise installiert ist.
=> Deinstallieren Sie zuerst diese Instanz von der Deinstallationsanwendung.
=> dann bereinigen, neu erstellen und versuchen, bereitzustellen.
Dies hat mein Problem gelöst. Ich hoffe, es hilft Ihnen auch. Freundliche Grüße.
quelle
Hatte auch dieses Problem - in meinem Fall wurde es dadurch verursacht, dass die Eigenschaft "Spezifische Version" für eine Reihe von Referenzen auf true gesetzt wurde. Wenn Sie dies für diese Referenzen in "false" ändern, wurde das Problem behoben.
quelle
Wenn ich NuGet verwenden wollte, musste ich nur Folgendes tun:
Klicken Sie mit der rechten Maustaste auf Projekt und klicken Sie auf NuGet-Pakete verwalten.
Klicken Sie oben rechts auf das Zahnrad
Klicken Sie im NuGet Package Manager über Paketquellen auf die Registerkarte Allgemein
Aktivieren Sie unter "Bindungsumleitungen überspringen" die Option "Bindungsumleitungen überspringen"
Reinigen und wieder aufbauen und die Warnung ist weg
Kinderleicht
quelle
Ich habe gerade irgendwann das gleiche Problem behoben. Beachten Sie, dass dieses Problem möglicherweise nicht zwischen verschiedenen Projekten besteht, sondern zwischen mehreren Referenzen in einem Projekt, die von verschiedenen Versionen derselben DLL / Assembly abhängen. In meinem Fall ging es um eine Nichtübereinstimmung der Referenzversionen
FastMember.dll
, die von zwei verschiedenen NuGet-Paketen in einem einzigen Projekt stammt. Wenn ich ein Projekt erhielt, wurde es nicht kompiliert, da NuGet-Pakete fehlten und VS sich weigerte, fehlende Pakete wiederherzustellen. Über das NuGet-Menü aktualisiere ich alle NuGets manuell auf die neueste Version, dh die Warnung wurde angezeigt.Tools > Options > Build and Run > MSBuld Project build output verbosity: (set to) Diagnostics.
Suchen Sie in Visual Studio nach den ZeilenThere was a conflict between
imOutput
Fenster. Unten ist der Teil der Ausgabe, den ich erhalten habe:Beachte das
Project file item includes which caused reference "C:\Users\ksd3jvp\Source\Temp\AITool\Misra\AMSAITool\packages\ClosedXML.0.94.2\lib\net46\ClosedXML.dll"
ClosedXML.dll
kommt vonClosedXML
NuGet und es kommt darauf anFastMember.dll 1.3.0.0
. Darüber hinaus gibt es auchFastMember
Nuget im Projekt, und das hat es auchFastMember.dll 1.5.0.0
. Nichtübereinstimmung!Ich habe
ClosedXML
&FastMember
NuGets deinstalliert , weil ich eine Bindungsumleitung hatte und nur die neueste Version von installiert habe.ClosedXML
Das hat das Problem behoben!quelle
Das ist mir auch passiert. Eine DLL wurde zweimal referenziert: einmal direkt (in Referenzen) und einmal indirekt (referenziert von einem anderen referenzierten Projekt). Ich habe die direkte Referenz entfernt, die Lösung gereinigt und neu aufgebaut. Problem gelöst.
quelle
In meinem Fall gab es ein Problem mit der MySQL-Referenz. Irgendwie könnte ich drei Versionen davon unter der Liste aller verfügbaren Referenzen auflisten; für .net 2.0, .net 4.0 und .net 4.5. Ich habe die obigen Prozesse 1 bis 6 befolgt und es hat bei mir funktioniert.
quelle
Eine andere Sache, die Sie berücksichtigen und überprüfen sollten, ist, sicherzustellen, dass kein Dienst ausgeführt wird, der diesen bin-Ordner verwendet. Wenn dies der Fall ist, beenden Sie den Dienst und erstellen Sie die Lösung neu
quelle
Unter Mac Visual Studio scheint beim Bearbeiten von .resx-Dateien ein Problem zu liegen. Ich weiß nicht genau, was passiert ist, aber ich habe dieses Problem, sobald ich einige .resx-Dateien auf meinem Mac bearbeitet habe. Ich habe das Projekt unter Windows geöffnet, die Dateien geöffnet und sie waren so, als wären sie nicht bearbeitet worden. Also habe ich sie bearbeitet, gespeichert und auch auf dem Mac hat alles wieder funktioniert.
quelle
Ich hatte ein solches Problem, als mein Projekt auf NETStandardLibrary verweist und eine der referenzierten Assemblys für Netcore veröffentlicht wurde. Gerade als netstandard veröffentlicht und Problem war weg
quelle
Hier ist die Lösung im .NET Core 3.0-Stil: https://github.com/HTD/ref-check
Wenn Sie herausfinden, welche Konflikte auftreten, können Sie die Konflikte möglicherweise lösen. Wenn die widersprüchlichen Referenzen aus anderen Paketen stammen, haben Sie entweder Pech oder müssen stattdessen Quellen verwenden.
In meinem Fall handelt es sich bei den in Konflikt stehenden Paketen häufig um eigene Pakete, sodass ich Abhängigkeitsprobleme beheben und erneut veröffentlichen kann.
quelle