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

320

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

ollifant
quelle

Antworten:

410

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) .
Brian Low
quelle
9
Nur für einen schnellen Weg, um es ohne das Dienstprogramm zu finden - wenn Sie die Bindungsumleitung hinzufügen (als Option 2), werden dort die betreffenden Referenzen angezeigt - falls gewünscht, können Sie dann eine der anderen Methoden verwenden Um damit umzugehen, löschen Sie die Bindungsumleitung (en) aus Ihrer Konfigurationsdatei.
Brisbe
222
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 Ausgabe von MSBuild-Projekten, Detailliert) und nach dem Erstellen das Ausgabefenster zu durchsuchen für die Warnung. Siehe den Text direkt darüber.
Pauloya
7
Die Bindungsumleitung durch Doppelklick auf Warnung (Schritt 2) entfernt meine Warnung nicht. Ich sehe, dass app.config mit der Assembly hinzugefügt wurde, von der ich vermute, dass sie die Ursache ist, aber die Warnung ist nach einer Bereinigung / Wiederherstellung immer noch vorhanden. Auch Schritt 3 zusätzlich versucht, kein Glück. Irgendwelche Ideen?
Angularsen
9
Was ist, wenn es sich nicht um Referenzen aus Ihren eigenen Projekten handelt? Zum Beispiel habe ich auf ein Projekt verwiesen, das von Newtonsoft.Json abhängig ist, Version = 6.0.0.0, und ich habe auf ein anderes Projekt verwiesen, das von Newtonsoft.Json abhängig ist, Version = 4.5.0.0
Edward Ned Harvey
3
@ brian-low, kann ich vorschlagen, die Einstellung für die Ausführlichkeit der Build-Ausgabe (wie im Kommentar von @pauloya vorgeschlagen) als Option in Ihrer Antwort neben dem verknüpften Dienstprogramm hinzuzufügen? (Haftungsausschluss, ich habe tatsächlich versucht, die Antwort zu bearbeiten, um genau das zu tun, aber es wurde bei der Überprüfung abgelehnt :))
Rick Riensche
44

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!

Matt Hamilton
quelle
31

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.

user1477388
quelle
3
Aber wie entferne ich den Fehler, nachdem ich diese Informationen habe? Ich kann sehen, was der Konflikt ist, aber ich kann nicht finden, wo das Projekt auf die widersprüchliche Version verweist
Bassie
Hallo @Bassie, das erste, was Sie tun müssen, ist, Ihre Nuget-Paketdatei zu überprüfen und festzustellen, ob Sie alle Dateien auf dieselbe Version des Pakets aktualisieren müssen. Sie können dies tun, indem Sie einen Befehl ausführen, derupdate-package [your package name] -version 6.0.0 -reinstall meiner Antwort hier ähnelt. Stackoverflow.com/questions/22685530/…
user1477388
@Bassie, Sie können das tun, was die Warnung vorschlägt, und die Bindungsumleitung zur Datei app.config hinzufügen! (Wenn eine Aktualisierung nicht möglich ist.)
BrainSlugs83
@Bassie siehe meine Antwort, wo ich Ihnen zeige, wie Sie verschiedene Assemblys / DLLs erhalten, die Probleme mit der Nichtübereinstimmung verursachen.
Newprint
22

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.

Gorgsenegger
quelle
1
Selbes Problem hier. Ich habe jedoch keine Möglichkeit, den Verweis auf eine neuere Version zu aktualisieren. Ich habe versucht, eine App.config zu verwenden: Während sie für die Anwendung funktioniert, scheint Visual Studio 2010 sie während der Erstellung zu ignorieren.
Thomas Weller
1
Wow, ich habe diese Probleme seit zwei Monaten und konnte sie nicht genau bestimmen und lösen. Aus irgendeinem Grund stürzte es nur während des Debuggens ab und in einigen Fällen ersetzte es manuell die lästige DLL durch die echte im bin-Ordner, wenn dies passieren würde. Das Debuggen war ein echtes Problem. Als ich Ihre Antwort las, wurde mir klar, dass genau das mit mir geschah, und ich habe es in etwa 5 Minuten
behoben
19

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.

Tiago Gouvêa
quelle
Danke für den Tipp. Diesmal hat es mir nicht geholfen, aber es ist gut zu wissen, dass es da ist.
BrainSlugs83
8

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

MoMo
quelle
9
Nur bis Sie die Lösung neu erstellen
Luke
Das rettet mich! Ich habe seit gestern eine andere Lösung versucht, aber diese hat mein Problem gelöst. Einschließlich des obigen Kommentars ^. Vielen Dank!
vnpnlz
6

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>
Phil50
quelle
Das war die Lösung für mich. Ich hatte eine verbindliche Weiterleitung zur höheren Version, die nur funktionierte, wenn ich zur niedrigeren Version wechselte.
Mrwaim
1
Warum? So seltsam für mich. Ich benutze EF nicht, aber ich dachte, wir wollen immer zur letzten Version wechseln?
Hoàng Long
1
@ HoàngLong, da die Version, auf die Sie verweisen, die ältere Version ist, aber die Version, die Sie einschließen, die neuere ist.
BrainSlugs83
3

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.

Rechnung
quelle
2

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.

Jon Limjap
quelle
2

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

Neelam Prajapati
quelle
1

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.

Tristan Lewis
quelle
1

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

0tombo0
quelle
1

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!

Newprint
quelle
0

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.

Igor Gorjanc
quelle
0
  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.

Sukhi
quelle
0

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

Telwa Gangnam
quelle
0

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.

Dpedrinha
quelle
0

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

Jacek Plesnar
quelle
0

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.

Harry
quelle