.net - Warnung: Konflikte zwischen verschiedenen Versionen derselben abhängigen Assembly gefunden


Ich entwickle gerade 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, wenn ich eine externe Komponente einbeziehe, ich immer die folgende Warnung bekomme:

"Found conflicts between different versions of the same dependent assembly".

Was genau bedeutet diese Warnung und gibt es möglicherweise eine Möglichkeit, diese Warnung auszuschließen (wie die Verwendung von #pragma disable in den Quellcodedateien)?



Answers



Diese Warnung bedeutet, dass zwei Projekte dieselbe Assembly (z. B. System.Windows.Forms ) referenzieren, die beiden Projekte jedoch unterschiedliche Versionen erfordern. Sie haben ein paar Optionen:

  1. Kompilieren Sie alle Projekte neu, um die gleichen Versionen zu verwenden (z. B. alles nach .Net 3.5 verschieben). Dies ist die bevorzugte Option, da der gesamte Code mit den Versionen von Abhängigkeiten ausgeführt wird, mit denen sie kompiliert wurden.

  2. Fügen Sie eine Bindungsumleitung hinzu . Dies unterdrückt die Warnung. Ihre .Net 2.0-Projekte werden jedoch (zur Laufzeit) an die .Net 3.5-Versionen von abhängigen Assemblys wie System.Windows.Forms gebunden. Sie können schnell eine Bindungsumleitung hinzufügen, indem Sie in Visual Studio auf einen Fehler doppelklicken.

  3. Verwenden Sie CopyLocal=true . Ich bin mir nicht sicher, ob dies die Warnung unterdrücken wird. Es wird wie Option 2 oben bedeuten, dass alle Projekte die .Net 3.5-Version von System.Windows.Forms verwenden werden.

Hier ist ein Dienstprogramm zum Identifizieren der fehlerhaften Referenz (en):

https://gist.github.com/1553265




Grundsätzlich passiert dies, wenn die Assemblys, auf die Sie verweisen, "Copy Local" auf "True" gesetzt haben, was bedeutet, dass eine Kopie der DLL zusammen mit Ihrer exe in den bin-Ordner platziert wird.

Da Visual Studio auch alle Abhängigkeiten einer referenzierten Assembly kopiert, ist es möglich, dass zwei verschiedene Builds der gleichen Assembly ausgegeben werden, auf die verwiesen wird. Dies ist wahrscheinlicher, wenn Ihre Projekte in separaten Lösungen sind und daher separat kompiliert werden können.

Ich habe mich damit beschäftigt, Copy Local auf False für Referenzen in Assembler-Projekten zu setzen. Tun Sie dies nur für ausführbare Dateien / Webanwendungen, bei denen Sie die Assembly für das fertige Produkt benötigen.

Hoffe das macht Sinn!




Ich wollte die Lösung von pauloya posten, die sie in den obigen Kommentaren angegeben haben. Ich glaube, es ist die beste Lösung, um die verletzenden Referenzen zu finden.

Der einfachste Weg, um herauszufinden, was die "verletzende Referenz" ist, ist das Setzen der Ausführlichkeit von Build-Ausgaben (Tools, Optionen, Projekte und Lösungen, Build und Run, Detaillierte Ausgabe von MSBuild-Projekt-Build-Ausgaben) und nach dem Erstellen des Ausgabefensters. für die Warnung. Siehe den Text direkt darüber.

Wenn Sie beispielsweise das Ausgabefenster nach "Konflikt" durchsuchen, finden Sie möglicherweise Folgendes:

3>  There was a conflict between "EntityFramework, Version=5.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" and "EntityFramework, Version=6.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089".
3>      "EntityFramework, Version=5.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" was chosen because it was primary and "EntityFramework, Version=6.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" was not.

Wie Sie sehen können, gibt es einen Konflikt zwischen den EF-Versionen 5 und 6.




Ich hatte das gleiche Problem mit einem meiner Projekte, aber keines der oben genannten half, die Warnung zu lösen. Ich überprüfte die ausführliche Build-Logdatei, ich benutzte AsmSpy, um zu überprüfen, ob ich die richtigen Versionen für jedes Projekt in der betroffenen Lösung verwendet habe. Ich habe die tatsächlichen Einträge in jeder Projektdatei doppelt geprüft - nichts half.

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) benötigte wiederum eine andere Version von (B), die direkt von allen anderen Projekten in meiner Lösung referenziert wurde. Das Aktualisieren der Referenz im referenzierten Projekt löste es.

Solution A
+--Project A
   +--Reference A (version 1.1.0.0)
   +--Reference B
+--Project B
   +--Reference A (version 1.1.0.0)
   +--Reference B
   +--Reference C
+--Project C
   +--Reference X (this indirectly references Reference A, but with e.g. version 1.1.1.0)

Solution B
+--Project A
   +--Reference A (version 1.1.1.0)

Ich hoffe, das obige zeigt was ich meine, brauchte ein paar Stunden, um es herauszufinden, also hoffentlich wird auch jemand anderes davon profitieren.




Ich hatte gerade diese Warnmeldung und bereinigte die Lösung und kompilierte (Build -> Clean Solution) und es ging weg.




Ich hatte das gleiche Problem und habe das Problem in der Datei web.config behoben.

Es passiert mir, weil ich die Anwendung mit Newtonsoft.Json 4.0 laufen lasse

Von:

<dependentAssembly>
  <assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" culture="neutral" />
  <bindingRedirect oldVersion="0.0.0.0-6.0.0.0" newVersion="6.0.0.0" />
</dependentAssembly>

Zu:

<dependentAssembly>
  <assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" culture="neutral" />
  <bindingRedirect oldVersion="0.0.0.0-6.0.0.0" newVersion="4.5.0.0" />
</dependentAssembly>



Wenn Sie in Visual Studio mit der rechten Maustaste auf die Lösung klicken und Nuget-Pakete verwalten, wird eine Registerkarte "Konsolidieren" angezeigt, in der alle Pakete auf dieselbe Version gesetzt werden.




Das hängt tatsächlich von Ihrer externen Komponente ab. Wenn Sie auf eine externe Komponente in einer .NET-Anwendung verweisen, wird eine GUID zum Identifizieren dieser Komponente generiert. Dieser Fehler tritt auf, wenn die externe Komponente, auf die von einem Ihrer Projekte verwiesen wird, denselben Namen und dieselbe Version wie eine andere 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, welche Projekte diese Konflikte haben, entfernen Sie die Komponenten aus der Referenzliste und fügen Sie sie erneut hinzu. Stellen Sie dabei sicher, dass Sie auf die gleiche Datei verweisen.




Ich habe einen anderen Weg, dies zu tun, wenn Sie Nuget verwenden, um Ihre Abhängigkeiten zu verwalten. Ich habe festgestellt, dass VS und Nuget manchmal nicht zusammenpassen und Nuget nicht erkennen kann, dass Ihre Projekte nicht synchron sind. Die packages.config sagt eine Sache, aber der in Referenzen - Eigenschaften gezeigte Pfad wird etwas anderes anzeigen.

Wenn Sie bereit sind, Ihre Abhängigkeiten zu aktualisieren, führen Sie die folgenden Schritte aus:

  1. Klicken Sie im Projektmappen-Explorer mit der rechten Maustaste auf das Projekt und klicken Sie auf "Nuget-Pakete verwalten".

  2. Wählen Sie im linken Fensterbereich die Registerkarte "Installierte Pakete" aus Nehmen Sie Ihre installierten Pakete auf Sie sollten Ihre packages.config zuerst auf Ihren Desktop kopieren, wenn Sie eine Menge haben. Sie können sie also mit Google überprüfen, um zu sehen, welche Nuget pkgs installiert sind.

  3. Deinstallieren Sie Ihre Pakete. Es ist OK, wir werden sie gleich wieder hinzufügen.

  4. Installieren Sie sofort die benötigten Pakete. Was Nuget tun wird, ist nicht nur, dass Sie die neueste Version erhalten, sondern auch Ihre Referenzen ändern und die verbindlichen Redirects für Sie hinzufügen.

  5. Tun Sie dies für alle Ihre Projekte.

  6. Führen Sie auf der Lösungsebene eine Reinigung und einen Neuaufbau durch.

Sie können mit den unteren Projekten beginnen und sich zu den höheren Projekten durcharbeiten und jedes Projekt während des Vorgangs neu erstellen.

Wenn Sie Ihre Abhängigkeiten nicht aktualisieren möchten, können Sie die Paketmanagerkonsole verwenden und die Syntax verwenden. Update-Package -ProjectName [IhrProjektname] [Paketname] -Version [Versionsnummer]




Hatte auch dieses Problem - in meinem Fall wurde es dadurch verursacht, dass die Eigenschaft "Spezifische Version" für eine Anzahl von Referenzen auf true gesetzt wurde. Wenn Sie diese Referenzen auf "false" setzen, wurde das Problem behoben.




=> Vergewissern Sie sich, dass einige Anwendungen teilweise installiert sind.

=> Deinstallieren Sie zuerst diese Instanz von der Deinstallationsanwendung.

=> dann, bereinigen, neu erstellen und versuchen, zu verteilen.

Das hat mein Problem gelöst. Hoffe es hilft dir auch. Freundliche Grüße.




Das ist mir auch passiert. Eine DLL wurde zweimal referenziert: einmal direkt (in Referenzen) und einmal indirekt (referenziert von einem anderen referenzierten Projekt). Ich entfernte direkte Referenz, säuberte u. Umgebaute Lösung. Problem gelöst.




  1. Öffnen Sie den "Projektmappen-Explorer".
  2. Klicken Sie auf "Alle Dateien anzeigen"
  3. Erweitern Sie "Referenzen"
  4. Sie sehen einen (oder mehrere) Verweis (e) mit einem leicht anderen Symbol als der Rest. In der Regel ist es eine gelbe Box, in der Sie eine Notiz machen sollten. Entferne es einfach.
  5. Fügen Sie den Verweis zurück und kompilieren Sie Ihren Code.
  6. Das ist alles.

In meinem Fall gab es ein Problem mit der MySQL-Referenz. Irgendwie konnte 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 Schritte 1 bis 6 oben befolgt und es hat für mich funktioniert.




Eine andere Sache zu prüfen und zu prüfen ist, stellen Sie sicher, dass Sie keinen Dienst ausgeführt haben, der diesen bin Ordner verwendet. wenn sie ist, stoppen Sie die Service- und Rebuild-Lösung