Es wurden Konflikte zwischen verschiedenen Versionen derselben abhängigen Assembly gefunden, die nicht gelöst werden konnten


371

Wenn ich meine Lösung mit mehreren Projekten bereinige und dann erstelle, meldet das Ausgabefenster, dass der Build erfolgreich war. Wenn ich jedoch das Fehlerlistenfenster ansehe , wird folgende Warnung angezeigt:

Es wurden Konflikte zwischen verschiedenen Versionen derselben abhängigen Assembly gefunden, die nicht gelöst werden konnten. Diese Referenzkonflikte werden im Erstellungsprotokoll aufgelistet, wenn die Protokollausführlichkeit auf detailliert eingestellt ist. C: \ Programme (x86) \ MSBuild \ 12.0 \ bin \ Microsoft.Common.CurrentVersion.targets

Wenn ich auf diese Nachricht doppelklicke, wird die Datei C: \ Programme (x86) \ MSBuild \ 12.0 \ bin \ Microsoft.Common.CurrentVersion.targets geöffnet, aber ich verstehe nichts darin.

Ich verwende Visual Studio Express 2013 für das Web.

Wie finde ich heraus, was falsch ist und mit welcher DLL und wie kann ich dann die Warnung aufheben?



2
Ich habe MS Connect vorgeschlagen, den DLL-Namen in die Nachricht connect.microsoft.com/VisualStudio/feedback/details/2619450 aufzunehmen
Michael Freidgeim

Antworten:


513

eta: Es gibt einen Killerartikel über dieses Zeug von SOs eigenem @Nick Craver , den du lesen solltest


Während die anderen Antworten dies sagen, machen sie es nicht explizit, also werde ich ...

In VS2013.2 müssen Sie die Nachricht nicht lesen, um die Ausgabe der zitierten Informationen tatsächlich auszulösen. Diese lautet:

C: \ Programme (x86) \ MSBuild \ 12.0 \ bin \ Microsoft.Common.CurrentVersion.targets (1697,5): Warnung MSB3277: Es wurden Konflikte zwischen verschiedenen Versionen derselben abhängigen Assembly gefunden, die nicht gelöst werden konnten. Diese Referenzkonflikte werden im Erstellungsprotokoll aufgelistet, wenn die Protokollausführlichkeit auf detailliert eingestellt ist .

Dies ist falsch (oder zumindest für einige Versionen von Visual Studio - es scheint bei einem aktuellen VS2015-Update 3 oder höher in Ordnung zu sein). Schalten Sie es stattdessen auf Diagnose (unter Extras-> Optionen-> Projekt und Lösungen-> Erstellen und Ausführen , stellen Sie die Ausführlichkeit der Ausgabe des MSBuild-Projektbuilds ein ), woraufhin Meldungen angezeigt werden wie:

Es gab einen Konflikt zwischen "Newtonsoft.Json, Version = 6.0.0.0, Kultur = neutral, PublicKeyToken = 30ad4fe6b2a6aeed" und "Newtonsoft.Json, Version = 6.0.5.17707, Kultur = neutral, PublicKeyToken = 30ad4fe6b2a6aeed".

  • "Newtonsoft.Json, Version = 6.0.0.0, Kultur = neutral, PublicKeyToken = 30ad4fe6b2a6aeed" wurde ausgewählt, weil es primär war, und "Newtonsoft.Json, Version = 6.0.5.17707, Kultur = neutral, PublicKeyToken = 30ad4fe6b2a6aeed" wurde nicht ausgewählt.

Dann

  • Ctrl-Alt-O um zum Ausgabefenster zu wechseln
  • Suche nach " wurde ausgewählt ", um den Drilldown zu finden.

... Und ja, für diejenigen, die sich die Details der [diagnostischen] Nachricht ansehen, war es eine6.x6.0.0.0 Neuigkeit für diesen Ignoranten, dass es in der Stadt eine Konvention gibt, nach der alle Versionen intern Assembly-Version sind , dh nur die SemVer Major-Komponente geht in die Assembly Version :)


3
Vielen Dank - ich benutze Visual Studio seit vielen Jahren und hatte nie ein Problem, das es erforderlich machte, so tief im Build-Protokoll zu graben. Ein anderes Problem, aber die Erkenntnis, dass die Informationen, die ich suchte, irgendwo ausgegeben wurden, lösten mein Problem.
Timothy Lee Russell

4
Die detaillierte Protokollstufe scheint in VS zu funktionieren (daher ist keine Diagnose erforderlich). Wäre aber nicht das erste Mal, dass sich MSBuild in VS anders verhält ...
Johannes Rudolph

105
Um die Ausführlichkeit des Protokolls über das Menü Extras-> Optionen zu ändern, suchen Sie nach Projekt und Lösungen-> Erstellen und Ausführen
Jenn

3
In meinem Fall hatte ich drei Konflikte und einer von ihnen war für die anderen beiden verantwortlich. Ich habe mein "detailliertes" Build-Protokoll in Notepad kopiert, nach "Konflikt" gesucht, das NuGet-Paket für die von mir erkannte Referenz aktualisiert und das Problem wurde behoben.
Isaac Lyman

@robotnik Danke für den Bearbeitungsvorschlag [der von anderen abgelehnt wurde]. Ich hatte die Informationen tatsächlich am Ende der Antwort eingefügt, aber hoffentlich ist die Antwort, wie sie jetzt ist, so klar, wie Sie es beabsichtigt haben.
Ruben Bartelink

76

Führen Sie msbuild Foo.sln /t:Rebuild /v:diag(von C:\Program Files (x86)\MSBuild\12.0\bin) aus, um Ihre Lösung über die Befehlszeile zu erstellen und weitere Details abzurufen. Suchen Sie dann die Lösung, die .csproj.die Warnung protokolliert, und überprüfen Sie die Referenzen und Referenzen anderer Projekte, die dieselbe allgemeine Assembly verwenden, die sich in der Version unterscheidet.

Bearbeiten: Sie können die Build-Ausführlichkeit auch direkt in VS2013 festlegen. Gehen Sie zum Menü Tools> Optionsund gehen Sie zu Projects and Solutionsund setzen Sie die Ausführlichkeit von MSBuild auf Diagnostic.

Edit: Wenige Klarstellungen, da ich selbst gerade eine bekommen habe. In meinem Fall war die Warnung darauf zurückzuführen, dass ich mithilfe der Resharper-Eingabeaufforderung eine Referenz hinzugefügt habe, im Gegensatz zum Dialogfeld "Referenz hinzufügen", das versionlos war, obwohl sowohl Version 4 als auch Version 12 zur Auswahl stehen.

<Reference Include="Microsoft.Build, Version=12.0.0.0, ..." />
<Reference Include="Microsoft.Build.Framework" />

vs.

<Reference Include="Microsoft.Build, Version=12.0.0.0, ..." />
<Reference Include="Microsoft.Build.Framework, Version=12.0.0.0, ..." />

Im MSBuild-Protokoll mit /v:diagAusführlichkeit sah es wie folgt aus. Angabe von Details, bei denen zwei Referenzen in Konflikt standen:

  There was a conflict between 
  "Microsoft.Build.Framework, Version=4.0.0.0, ..." and 
  "Microsoft.Build.Framework, Version=12.0.0.0, ...". (TaskId:16)

      "Microsoft.Build.Framework, Version=4.0.0.0, ..." was chosen because it was primary and 
      "Microsoft.Build.Framework, Version=12.0.0.0, ..." was not. (TaskId:16)

      References which depend on "Microsoft.Build.Framework, Version=4.0.0.0, ..." 
      [C:\...\v4.5.1\Microsoft.Build.Framework.dll]. (TaskId:16)

          C:\...\v4.5.1\Microsoft.Build.Framework.dll (TaskId:16)
            Project file item includes which caused reference "C:\...\v4.5.1\Microsoft.Build.Framework.dll". (TaskId:16)
              Microsoft.Build.Framework (TaskId:16)

      References which depend on "Microsoft.Build.Framework, Version=12.0.0.0, ..." 
      [C:\...\v12.0\Microsoft.Build.Framework.dll]. (TaskId:16)

          C:\...\v12.0\Microsoft.Build.dll (TaskId:16)
            Project file item includes which caused reference "C:\...\v12.0\Microsoft.Build.dll". (TaskId:16)
              Microsoft.Build, Version=12.0.0.0, ... (TaskId:16)

          C:\...\v12.0\Microsoft.Build.Engine.dll (TaskId:16)
            Project file item includes which caused reference "C:\...\v12.0\Microsoft.Build.Engine.dll". (TaskId:16)
              Microsoft.Build, Version=12.0.0.0, ... (TaskId:16)

C:\Program Files (x86)\MSBuild\12.0\bin\Microsoft.Common.CurrentVersion.targets(1697,5): warning MSB3277: 
Found conflicts between different versions of the same dependent assembly that could not be resolved.  
These reference conflicts are listed in the build log when log verbosity is set to detailed. 
[C:\Users\Ilya.Kozhevnikov\Dropbox\BuildTree\BuildTree\BuildTree.csproj]

10
msbuild "Foo.sln" /t:Rebuild /v:d > build.log
Am

2
Der beste Weg, um zum Terminal zu gelangen: stackoverflow.com/a/22702405/268066
CrazyPyro

@CrazyPyro msbuild hat eine "eingebaute" Pipe - /l:FileLogger,Microsoft.Build.Engine;logfile=build.log- beachten Sie die Schalter für Logger Erklärung hier
drzaus

3
Wo befindet sich das "Build Log"? Wie finde ich es?
Gefangener NULL

Diese Antwort zeigt, wie Sie mehr Details von msbuild erhalten, was einem Mono-Benutzer wichtig ist. Bei allen anderen Antworten wird davon ausgegangen, dass Sie VS verwenden und in einer Windows-Umgebung ausgeführt werden.
UnconditionallyReinstateMonica

39

Ich kann die weitere Antwort von Ruben nur mit einem Vergleich zwischen den beiden angezeigten Nachrichten unterstützen:

Geben Sie hier die Bildbeschreibung ein

und die Nachricht:

C: \ Programme (x86) \ MSBuild \ 12.0 \ bin \ Microsoft.Common.CurrentVersion.targets (1697,5): Warnung MSB3277: Es wurden Konflikte zwischen verschiedenen Versionen derselben abhängigen Assembly gefunden, die nicht gelöst werden konnten. Diese Referenzkonflikte werden im Erstellungsprotokoll aufgeführt, wenn die Ausführlichkeit des Protokolls festgelegt ist detailliert eingestellt ist .

Also, Ruben hat recht - das ist einfach nicht wahr. Es gibt keinerlei Konflikte, nur eine fehlende Baugruppe. Dies ist besonders langweilig, wenn es sich bei dem Projekt um eine ASP.NET-Anwendung handelt, da die Ansichten bei Bedarf kompiliert werden, dh kurz vor der ersten Anzeige. In diesem Fall muss die Baugruppe verfügbar sein. (Es gibt eine Option zum Vorkompilieren der Ansichten zusammen mit dem Rest des Codes, aber dies ist eine andere Geschichte .) Wenn Sie andererseits die Ausführlichkeit auf Diagnose setzen, erhalten Sie die folgende Ausgabe:

C: \ Programme (x86) \ MSBuild \ 12.0 \ bin \ Microsoft.Common.CurrentVersion.targets (1697,5): Warnung MSB3245: Dieser Verweis konnte nicht aufgelöst werden. Die Assembly "System.Web.Razor, Version = 3.0.0.0, Kultur = neutral, PublicKeyToken = 31bf3856ad364e35, Prozessorarchitektur = MSIL" konnte nicht gefunden werden.Stellen Sie sicher, dass die Assembly auf der Festplatte vorhanden ist. Wenn diese Referenz von Ihrem Code benötigt wird, können Kompilierungsfehler auftreten.

Als Ergebnis müssen Sie entweder:

  1. Fügen Sie manuell einen Verweis auf die Assembly hinzu (suchen Sie ihn auf der Festplatte, möglicherweise im GAC, und fügen Sie ihn als "direkten" Verweis hinzu), oder
  2. Verwenden Sie das NuGet-Paket (falls in der Galerie veröffentlicht), um es herunterzuladen und auf die darin enthaltene Assembly zu verweisen.

Mehr zur NuGet Galerie hier . Weitere Informationen zum Vorkompilieren von ASP.NET-Ansichten finden Sie hier .


Wenn ich in VS 2017 die Ausführlichkeit "Ausgabe des MSBuild-Projekts erstellen" (nicht die Protokolldatei) auf "Detailliert" (nicht "Diagnose") setzte, wurde in meinem Ausgabefenster der Fehler "Assembly konnte nicht gefunden werden" angezeigt.
ALEXintlsos

@ALEXintlsos: Anscheinend hat sich diese Funktionalität geändert. Trotzdem haben Sie den Fehler überall dort erhalten, wo er ist. Befolgen Sie die Anweisungen, um ihn zu entfernen.
Alexander Christov

22

Das Ändern der Build-Ausführlichkeit in Visual Studio hilft dabei, in die richtige Richtung zu weisen. Führen Sie die folgenden Schritte aus, um die Ausführlichkeit in VS zu ändern

  1. Gehen Sie in VS zum Menü Extras-> Optionen
  2. Öffnen Sie Projekte und Lösungen-> Erstellen und Ausführen
  3. Ändern Sie den Wert der Ausführlichkeit der Ausgabe des MSBuild-Projekts. Wählen Sie eine aus Quiet, Minimal, Normal, DetailedundDiagnostic

Überprüfen Sie das Ausgabefenster ( Ctrl+ Alt+ O) in VS, um die Änderungen im Erstellungsprotokoll anzuzeigen.


16

und wie mache ich dann die Warnung weg?

Sie müssen wahrscheinlich Ihre NuGet-Pakete neu installieren oder aktualisieren, um dies zu beheben.


2
Dies löste das Problem für mich mit einer Kombination aus einem Neustart von Visual Studio, wenn es sich weigerte, ein Paket ordnungsgemäß neu zu installieren.
Ohad Schneider

22
Einfachste Möglichkeit zur Überprüfung: Klicken Sie mit der rechten Maustaste auf Lösung -> Manage NuGet packages for solution-> Unter können ConsolidateSie sehen, ob verschiedene Versionen desselben Pakets installiert wurden
elshev

16

Wiederholen eines der Kommentare von @elshev Klicken Sie mit der rechten Maustaste auf die Lösung -> NuGet-Pakete für Lösung verwalten -> Unter Konsolidieren können Sie sehen, ob verschiedene Versionen desselben Pakets installiert wurden. Aktualisieren Sie die Pakete dort. Der Konfliktfehler ist behoben.


1
das hat sich für mich nicht gelöst. Ich musste Newtonsoft.JSON deinstallieren und über NuGet neu installieren. Dadurch wurden die Abhängigkeiten von den anderen Paketen aktualisiert.
Garr Godfrey

Dies ist mir auch passiert, wenn ich Tools wie Resharper verwendet habe, die automatisch fehlende DLL-Referenzen hinzufügen. "Immer mit Nuget hinzufügen" könnte hier ein guter Vorschlag sein.
Shaswat Rungta

Bei mir funktioniert das nicht, da beim Deinstallieren eines Pakets ein Build versucht wird, der aufgrund eines Paketkonflikts nicht möglich ist. Daher kann ich das Paket nicht einmal neu installieren :(
nickornotto

8

Ich verwende Visual Studio 2017 und bin darauf gestoßen, als ich einige Nuget-Pakete aktualisiert habe. Was für mich funktionierte, war, meine web.configDatei zu öffnen , den <runtime><assemblyBinding>Knoten zu finden und ihn zu löschen. Speichern Sie web.configdas Projekt und erstellen Sie es neu.

Schau dir das Error ListFenster an. Sie werden sehen, wie eine massiv lange Warnung vor verbindlichen Konflikten aussieht. Doppelklicken Sie darauf und der <runtime><assemblyBinding>Block wird automatisch mit den richtigen Zuordnungen neu erstellt.



3

Ich könnte diese Installation von Newtonsoft Json im Webprojekt mit Nugget-Paketen lösen


3

Offensichtlich gibt es viele verschiedene Ursachen und damit viele Lösungen für dieses Problem. Um meine in den Mix zu integrieren, haben wir eine Assembly (System.Net.Http), auf die zuvor in unserem Webprojekt direkt verwiesen wurde, auf eine von NuGet verwaltete Version aktualisiert. Dadurch wurde die direkte Referenz innerhalb dieses Projekts entfernt, aber unser Testprojekt enthielt immer noch die direkte Referenz. Durch das Aktualisieren beider Projekte zur Verwendung der von NuGet verwalteten Assembly wurde das Problem behoben.


2

Wenn Sie Änderungen an Paketen vorgenommen haben, öffnen Sie die SLN erneut. Das hat bei mir funktioniert!


1

Ich habe festgestellt, dass manchmal Nuget-Pakete installiert werden (was ich vermute). Erforderliche .NET Core-Komponenten oder andere Elemente, die mit dem bereits installierten Framework in Konflikt stehen. Meine Lösung bestand darin, die Projektdatei (.csproj) zu öffnen und diese Referenzen zu entfernen. Beispielsweise werden System.IO, System.Threading und dergleichen normalerweise hinzugefügt, wenn Microsoft.Bcl über ein kürzlich installiertes NuGet-Paket enthalten ist. Es gibt keinen Grund für bestimmte Versionen in meinen Projekten, daher entferne ich die Referenzen und die Projekterstellung. Ich hoffe, das hilft.

Sie können Ihre Projektdatei nach "Referenz" durchsuchen und die Konflikte beseitigen. Wenn sie in System enthalten sind, entfernen Sie sie, und der Build sollte funktionieren. Dies beantwortet möglicherweise nicht alle Fälle dieses Problems - ich stelle sicher, dass Sie wissen, was bei mir funktioniert hat :)

Beispiel für das, was ich auskommentiert habe:

<!-- <Reference Include="System.Runtime, Version=2.6.9.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL"> -->
  <!-- <HintPath>$(SolutionDir)packages\Microsoft.Bcl.1.1.9\lib\net40\System.Runtime.dll</HintPath> -->
  <!-- <Private>True</Private> -->
<!-- </Reference> -->


1

Ich folgte dem Rat einiger der Antworten hier, um herauszufinden, was falsch war, aber keine der Antworten schien zu erklären, wie man das Problem behebt. Mein Problem war, dass für eine Referenz eine andere Version einer zweiten Referenz erforderlich war. Newtonsoft war also in Version 6, aber eine andere DLL wollte 4.5. Dann habe ich Newtonsoft aktualisiert, wie eine der anderen Antworten vorschlug, und das machte die Sache noch schlimmer.

Also habe ich meine Newtonsoft-Installation tatsächlich herabgestuft und die Warnung ging weg (VS 2017):

Klicken Sie im Lösungs-Explorer mit der rechten Maustaste auf Referenzen, und wählen Sie NuGet-Pakete verwalten aus. Suchen Sie auf der Registerkarte "Installiert" nach Newtonsoft (oder was auch immer Ihr Konflikt ist). Auf der rechten Seite wird neben "Version" ein Dropdown-Menü angezeigt, das Sie auf "Älter" ändern können Versionen. Mir war nicht klar, dass dieses Dropdown zum Downgrade verwendet werden kann.


1

Sie können die Dotnet-CLI mit vollständiger diagnostischer Ausführlichkeit ausführen, um das Problem zu finden.

dotnet run --verbosity diagnostic >> full_build.log

Sobald der Build abgeschlossen ist, können Sie die Protokolldatei (full_build.log) nach dem Fehler durchsuchen. Wenn Sie beispielsweise nach "einem Konflikt" suchen, sollten Sie direkt zum Problem gelangen.


0

Ich habe Microsoft ASP.NET MVC nuget.org von NuGet Packagaes verwaltet und erneut installiert. Während der Neuinstallation wurden alle Konflikte im Zusammenhang mit der Rasiermesserversion behoben. Versuch es .


0

Ich habe die Ausführlichkeit von MSBuild in Diagnostic geändert, konnte aber nicht finden, wo das Problem lag. Entsprechend den obigen Antworten hatte ich diesen Code in app.config:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
<configSections>
<section name="log4net" type="log4net.Config.Log4NetConfigurationSectionHandler, log4net" />
<sectionGroup name="userSettings" type="System.Configuration.UserSettingsGroup, System, Version=12.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089">
<section name="XbimXplorer.Properties.Settings" type="System.Configuration.ClientSettingsSection, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" allowExeDefinition="MachineToLocalUser" requirePermission="false" />
</sectionGroup>
</configSections>
<startup>
<supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.5" />
</startup>

Also habe ich gerade das erste System, Version von 4.0.0.0 auf 12.0.0.0 geändert und mein Projekt hat funktioniert.


0

Stellen Sie gemäß den anderen Antworten die Ausgabeprotokollierungsstufe auf detailliert ein und suchen Sie dort nach Konflikten, die Ihnen sagen, wo Sie als Nächstes suchen müssen.

In meinem Fall schickte es mich in ein paar Richtungen auf die Suche nach der Quelle der Referenzen, aber am Ende stellte sich heraus, dass das Problem eines meiner tragbaren Klassenbibliotheksprojekte war, es zielte auf die falsche Version ab und zog seine eigene Version der Referenzen in, daher die Konflikte. Ein schnelles Re-Targeting und das Problem wurde gelöst.


0

Ich bin gerade auf dieses und das Problem gestoßen, nachdem ich ein Paket von Nuget auf lokal referenzierte DLLs umgestellt hatte. Das Problem war altes Laufzeitbindungsmaterial in app.config.


0

Ich hatte diese Warnung nach der Migration zur Paketreferenz. In der Diagnoseausgabe gab es Informationen, dass die Bibliothek von derselben Bibliothek selbst referenziert wurde. Möglicherweise liegt ein Fehler in der neuen Paketreferenz vor. Die Lösung bestand darin, AutoGenerateBindingRedirects zu aktivieren und die benutzerdefinierte Bindungsumleitung zu löschen.


0

VS 2017, MVC-Projekt

Ich weiß nicht warum, aber für mich bestand die Lösung für dieses Problem darin, einen outParameter aus einer Modellmethoden-Signatur zu entfernen , die von der Controller-Aktionsmethode aufgerufen wurde. Das ist ein sehr seltsames Verhalten, aber das war die Lösung für mein Problem.


-2

Lauf Update-Package Befehl über die Package Manager-Konsole aus

Dadurch wird MSB3277 behoben. Dadurch werden alle Pakete und alle zugehörigen Assemblys, mit denen sie geliefert werden, auf die höchstmögliche Version neu installiert . Es ist auch möglich, nur ein bestimmtes Paket zu aktualisieren. Oder Downgrade nach dem Update, falls gewünscht, dieses Problem wurde für mich einige Male behoben. Je nachdem, wie viele Nuget-Pakete Sie haben, kann dieser Vorgang einige Minuten dauern.

Weitere Informationen zu offiziellen Dokumenten finden Sie unter https://docs.microsoft.com/en-us/nuget/consume-packages/reinstalling-and-updating-packages


14
Dieser Rat kann Ihren Tag ruinieren, wenn Sie nicht die neuesten Pakete möchten, was häufig beim Produktionscode der Fall ist.
Tony O'Hagan

1
Dies wird in den Ratschlägen angegeben. Was für Sie möglicherweise ein Problem darstellt, ist eine sichere und einfache Möglichkeit, ein Problem zu beheben. Bitte stimmen Sie die Leute nicht nach Ihrer eigenen Meinung ab.
Aistis Taraskevicius

1
Diese Lösung hat bei mir nicht funktioniert. Ich hatte bereits die neuesten Versionen.
Zero3

@ Zero3 haben Sie es von Ihrer Top-Lösung ausgeführt, ohne ein Paket direkt anzugeben, es funktioniert normalerweise, weil es jedes einzelne neu installiert und Referenzen aktualisiert, was zu Fehlanpassungen führt
Aistis Taraskevicius

3
Das ist wirklich ein schrecklicher Rat. Es ist keine Meinung, dass das Aktualisieren von Paketen den Code bricht, wenn dies nicht mit Absicht erfolgt.
TheBatman
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.