Warnung: Es wurden Konflikte zwischen verschiedenen Versionen derselben abhängigen Assembly gefunden

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)?

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:

1. 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.

2. 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.

3. 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:

• Sie können ein Dienstprogramm wie das unter https://gist.github.com/1553265 verwendete verwenden
• Eine andere einfache Methode besteht darin, die Ausführlichkeit der Build-Ausgabe festzulegen (Tools, Optionen, Projekte und Lösungen, Erstellen und Ausführen, Ausführlichkeit der Ausgabe der MSBuild-Projekterstellung, Detailliert) und nach dem Erstellen das Ausgabefenster nach der Warnung zu durchsuchen und den Text direkt darüber anzuzeigen . ( Hutspitze an Pauloya, der dies in den Kommentaren zu dieser Antwort vorgeschlagen hat) .

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!

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.

Der einfachste Weg, um die "beleidigenden Referenzen" zu finden, besteht darin, die Ausführlichkeit der Build-Ausgabe festzulegen (Tools, Optionen, Projekte und Lösungen, Erstellen und Ausführen, Ausführliche Ausführlichkeit der MSBuild-Projekterstellung, Detailliert) und nach dem Erstellen das Ausgabefenster zu durchsuchen für die Warnung. Siehe den Text direkt darüber.

Wenn Sie beispielsweise das Ausgabefeld 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, besteht ein Konflikt zwischen den EF-Versionen 5 und 6.

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.

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. Ich habe ein paar Stunden gebraucht, um es herauszufinden. Hoffentlich wird auch jemand anderes davon profitieren.

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.

Ich hatte gerade diese Warnmeldung und bereinigte die Lösung und kompilierte sie neu (Build -> Clean Solution) und sie verschwand.

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:

<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>

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:

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 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

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

4. 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.

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

6. 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.

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.

=> Ü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.

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.

Wenn ich NuGet verwenden wollte, musste ich nur Folgendes tun:

1. Klicken Sie mit der rechten Maustaste auf Projekt und klicken Sie auf NuGet-Pakete verwalten.

2. Klicken Sie oben rechts auf das Zahnrad

3. Klicken Sie im NuGet Package Manager über Paketquellen auf die Registerkarte Allgemein

4. Aktivieren Sie unter "Bindungsumleitungen überspringen" die Option "Bindungsumleitungen überspringen"

5. Reinigen und wieder aufbauen und die Warnung ist weg

Kinderleicht

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 Zeilen There was a conflict betweenim OutputFenster. Unten ist der Teil der Ausgabe, den ich erhalten habe:

1>  There was a conflict between "FastMember, Version=1.5.0.0, Culture=neutral, PublicKeyToken=null" and "FastMember, Version=1.3.0.0, Culture=neutral, PublicKeyToken=null". (TaskId:19)
1>      "FastMember, Version=1.5.0.0, Culture=neutral, PublicKeyToken=null" was chosen because it was primary and "FastMember, Version=1.3.0.0, Culture=neutral, PublicKeyToken=null" was not. (TaskId:19)
1>      References which depend on "FastMember, Version=1.5.0.0, Culture=neutral, PublicKeyToken=null" [C:\Users\ksd3jvp\Source\Temp\AITool\Misra\AMSAITool\packages\FastMember.1.5.0\lib\net461\FastMember.dll]. (TaskId:19)
1>          C:\Users\ksd3jvp\Source\Temp\AITool\Misra\AMSAITool\packages\FastMember.1.5.0\lib\net461\FastMember.dll (TaskId:19)
1>            Project file item includes which caused reference "C:\Users\ksd3jvp\Source\Temp\AITool\Misra\AMSAITool\packages\FastMember.1.5.0\lib\net461\FastMember.dll". (TaskId:19)
1>              FastMember, Version=1.5.0.0, Culture=neutral, processorArchitecture=MSIL (TaskId:19)
1>      References which depend on "FastMember, Version=1.3.0.0, Culture=neutral, PublicKeyToken=null" []. (TaskId:19)
1>          C:\Users\ksd3jvp\Source\Temp\AITool\Misra\AMSAITool\packages\ClosedXML.0.94.2\lib\net46\ClosedXML.dll (TaskId:19)
1>            Project file item includes which caused reference "C:\Users\ksd3jvp\Source\Temp\AITool\Misra\AMSAITool\packages\ClosedXML.0.94.2\lib\net46\ClosedXML.dll". (TaskId:19)
1>              ClosedXML, Version=0.94.2.0, Culture=neutral, processorArchitecture=MSIL (TaskId:19)

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.dllkommt von ClosedXMLNuGet und es kommt darauf an FastMember.dll 1.3.0.0. Darüber hinaus gibt es auch FastMemberNuget im Projekt, und das hat es auch FastMember.dll 1.5.0.0. Nichtübereinstimmung!

Ich habe ClosedXML& FastMemberNuGets deinstalliert , weil ich eine Bindungsumleitung hatte und nur die neueste Version von installiert habe. ClosedXMLDas hat das Problem behoben!

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.

1. Öffnen Sie den "Projektmappen-Explorer".
2. Klicken Sie auf "Alle Dateien anzeigen"
3. Erweitern Sie "Referenzen"
4. Sie sehen eine (oder mehrere) Referenz (en) mit einem etwas anderen Symbol als die anderen. In der Regel wird ein gelbes Kästchen angezeigt, in dem Sie aufgefordert werden, dies zu notieren. Entfernen Sie es einfach.
5. Fügen Sie die Referenz zurück und kompilieren Sie Ihren Code.
6. Das ist alles.

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.

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

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.

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

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.