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

Question

Ich entwickle derzeit eine .NET-Anwendung, die aus 20 Projekten besteht. Einige dieser Projekte werden mit .NET 3.5 kompiliert, andere sind immer noch .NET 2.0-Projekte (bisher kein Problem).

Das Problem ist, dass ich immer die folgende Warnung erhalte, wenn ich eine externe Komponente einbinde:

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

Was genau bedeutet diese Warnung und gibt es vielleicht eine Möglichkeit, diese Warnung auszuschließen (zum Beispiel durch Verwendung von #pragma disable in den Quellcodedateien)?

Answer 1

Diese Warnung bedeutet, dass zwei Projekte auf die gleiche Assembly verweisen (z.B. System.Windows.Forms), aber die beiden Projekte unterschiedliche Versionen benötigen. Sie haben ein paar Optionen:

1. Kompilieren Sie alle Projekte neu, um die gleichen 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 läuft, mit denen er kompiliert wurde.

2. Fügen Sie eine binde Referenz hinzu. Dadurch wird die Warnung unterdrückt. Allerdings werden Ihre .Net 2.0-Projekte (im Laufzeitmodus) an die .Net 3.5-Versionen von abhängigen Assemblys wie System.Windows.Forms gebunden. Sie können schnell eine Verweisbindung hinzufügen, indem Sie in Visual Studio auf den Fehler doppelklicken.

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

Hier sind ein paar Möglichkeiten, die fehlerhafte(n) Referenz(en) zu identifizieren:

• Sie können ein Dienstprogramm wie das unter https://gist.github.com/1553265 finden
• Ein weiterer einfacher Weg ist, den Build Ausgabeverbosenheit (Tools, Optionen, Projekte und Lösungen, Build und Ausführen, MSBuild-Projektbuildausgabeverbosität, Detailliert) zu setzen und nach dem Bau, suchen Sie im Ausgabefenster nach der Warnung und sehen Sie sich den Text direkt darüber an. (Dank an pauloya, der dies in den Kommentaren zu dieser Antwort vorgeschlagen hat).

Answer 2

Grundsätzlich passiert das, wenn die Assemblys, auf die Sie verweisen, auf "Copy Local" auf "True" gesetzt sind, was bedeutet, dass eine Kopie der DLL zusammen mit Ihrer exe im Bin-Ordner platziert wird.

Da Visual Studio alle Abhängigkeiten einer referenzierten Assembly kopiert, ist es möglich, dass zwei verschiedene Builds derselben Assembly referenziert werden. Dies ist wahrscheinlicher, wenn Ihre Projekte in separaten Lösungen sind und daher separat kompiliert werden können.

Der Weg, wie ich das umgangen habe, ist "Copy Local" für Verweise in Assembly-Projekten auf "False" zu setzen. Machen Sie das nur für ausführbare/web Anwendungen, bei denen Sie die Assembly für das fertige Produkt benötigen, um ausgeführt zu werden.

Hoffe, das macht Sinn!

Answer 3

Ich wollte die Lösung von pauloya posten, die sie oben in den Kommentaren bereitgestellt haben. Ich glaube, es ist die beste Lösung, um die problematischen Verweise zu finden.

Der einfachste Weg, um herauszufinden, was die "problematischen Verweise" sind, besteht darin, die Ausgabeverbosität für den Build festzulegen (Tools, Optionen, Projekte und Lösungen, Build und Ausführung, MSBuild-Projekt-Bauausgabenverhalten, Detailliert) und nach dem Build in der Ausgabewindow nach der Warnung zu suchen. Sehen Sie den Text direkt darüber.

Wenn Sie beispielsweise in der Ausgabekonsole nach "Konflikt" suchen, finden Sie möglicherweise etwas Ähnliches wie dies:

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.

Answer 4

Auf Visual Studio, wenn Sie mit der rechten Maustaste auf die Lösung klicken und NuGet-Pakete verwalten, gibt es einen "Konsolidieren"-Tab, der alle Pakete auf dieselbe Version setzt.

Answer 5

Ich hatte dasselbe Problem mit einem meiner Projekte, jedoch hat keines der oben genannten Dinge geholfen, um die Warnung zu lösen. Ich habe das ausführliche Build-Logfile überprüft, ich habe AsmSpy verwendet, um zu bestätigen, dass ich die korrekten Versionen für jedes Projekt in der betroffenen Lösung verwendet habe, ich habe die tatsächlichen Einträge in jeder Projektdatei überprüft - nichts hat geholfen.

Letztendlich stellte sich heraus, dass das Problem eine verschachtelte Abhängigkeit eines der Referenzen war, die ich in einem Projekt hatte. Diese Referenz (A) erforderte 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 hat es gelöst.

Lösung A
+--Projekt A
   +--Referenz A (Version 1.1.0.0)
   +--Referenz B
+--Projekt B
   +--Referenz A (Version 1.1.0.0)
   +--Referenz B
   +--Referenz C
+--Projekt C
   +--Referenz X (das indirekt Referenz A referenziert, aber z.B. Version 1.1.1.0)

Lösung B
+--Projekt A
   +--Referenz A (Version 1.1.1.0)

Ich hoffe, das obige zeigt, was ich meine. Es hat mich ein paar Stunden gekostet, um herauszufinden, sodass hoffentlich auch jemand anders davon profitieren wird.