it-swarm.com.de

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

Wenn ich meine Lösung mit mehreren Projekten bereinige und dann baue, meldet das Ausgabefenster, dass der Build erfolgreich war. Wenn ich jedoch das Error List-Fenster sehe, wird mir diese Warnung angezeigt:

Es wurden Konflikte zwischen verschiedenen Versionen derselben abhängigen Assembly gefunden, die nicht aufgelöst werden konnten. Diese Referenzkonflikte werden im Erstellungsprotokoll aufgeführt, wenn die Ausführlichkeit der Protokolle detailliert 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. Ich verstehe jedoch 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?

298
Water Cooler v2

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

Um die Ausgabe der genannten Informationen auszulösen, müssen Sie in VS2013.2 die Nachricht nicht lesen, die besagt:

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 aufgelöst werden konnten. Diese Referenzkonflikte werden im Erstellungsprotokoll aufgeführt, wenn die Protokoll Ausführlichkeit auf detailliert gesetzt ist.

Dies ist falsch (oder war zumindest in einigen Versionen von Visual Studio der Fall - bei VS2015 Update 3 oder höher scheint es in Ordnung zu sein). Stellen Sie es stattdessen auf Diagnostic (von Tools-> Options-> Project and Solutions-> Build and Run, und setzen Sie MSBuild-Projekterstellungsausgabe). Daraufhin werden Sie Siehe Nachrichten 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" nicht.

Dann

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

... Und ja, für diejenigen, die sich die Details der [diagnostischen] Nachricht ansehen, war es eine Neuigkeit für diesen Ignoranten, dass es in der Stadt eine Konvention gibt, bei der alle 6.x-Versionen intern Versionsversion 6.0.0.0 sind, dh nur die SemVer Major-Komponente geht in die Montageversion :)

422
Ruben Bartelink

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 ein wenig mehr Details zu erhalten. Suchen Sie dann den .csproj., der die Warnung protokolliert, und überprüfen Sie die Referenzen und Referenzen anderer Projekte, die dieselbe gemeinsame Assembly verwenden, die sich in ihrer Version unterscheidet.

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

Edit: Wenige Klarstellungen, da ich gerade selbst eine bekam. In meinem Fall war die Warnung darauf zurückzuführen, dass ich einen Verweis mit der Eingabeaufforderung von Resharper hinzugefügt habe, im Gegensatz zum Dialogfeld "Verweis hinzufügen", bei dem es versionlos war, obwohl sowohl v4 als auch v12 verfügbar sind.

<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:diag-Ausführlichkeit sah es folgendermaßen aus. mit Details, die zwei Referenzen miteinander in Konflikt stehen:

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

Ich kann die Antwort von Ruben nur unterstützen, wenn ich die beiden angezeigten Nachrichten miteinander vergleicht:

enter image description here

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 aufgelöst werden konnten. Diese Referenzkonflikte werden im Erstellungsprotokoll aufgelistet, wenn die Ausführlichkeit der Protokolle auf detail gesetzt ist.

Rubens hat also recht - das stimmt einfach nicht. Es gibt keinerlei Konflikte, nur eine fehlende Versammlung. Dies ist besonders langweilig, wenn es sich bei dem Projekt um eine ASP.NET-Anwendung handelt, da die Ansichten on demand kompiliert werden, d. H. Kurz vor der ersten Anzeige. In diesem Fall wird es notwendig, die Assembly zur Verfügung zu haben. (Es gibt eine Option, die Ansichten zusammen mit dem restlichen Code vorab zu kompilieren, dies ist jedoch eine andere Geschichte .) Wenn Sie andererseits die Ausführlichkeit auf Diagnostic 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 konnte nicht gefunden werden "System.Web.Razor, Version = 3.0.0.0, Culture = neutral, PublicKeyToken = 31bf3856ad364e35, processorArchitecture = MSIL". Überprüfen Sie, ob die Assembly auf der Festplatte vorhanden ist. Wenn diese Referenz von Ihrem Code benötigt wird, können Kompilierungsfehler auftreten.

Alles was Sie tun müssen, ist entweder:

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

Mehr über die NuGet-Galerie hier . Weitere Informationen zum Vorkompilieren von ASP.NET-Ansichten hier .

34

Wiederholen Sie einen 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 des gleichen Pakets installiert wurden. Aktualisieren Sie die Pakete dort. Der Konfliktfehler wurde behoben.

15
Shaswat Rungta

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ührlichen Ausgabe des MSBuild-Projektbuilds. Wählen Sie eine aus Quiet, Minimal, Normal, Detailed und Diagnostic

Überprüfen Sie das Ausgabefenster (Ctrl+Alt+O) in VS, um die Änderungen im Build-Protokoll zu sehen.

15
sree

und wie kann ich dann die Warnung verschwinden lassen?

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

14
CrazyPyro

Wie in dotnet CLI Ausgabe 6583 angegeben, sollte das Problem mit dem Befehl dotnet nuget locals --clear all gelöst werden.

6
Jose L. Garcia

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

Schauen Sie sich das Error List-Fenster an. Sie werden sehen, wie eine massiv lange Warnung vor verbindlichen Konflikten aussieht. Doppelklicken Sie darauf, um den Block <runtime><assemblyBinding> mit den korrekten Zuordnungen automatisch neu zu erstellen. 

5
RandomHandle

Ich könnte das Installieren von Newtonsoft Json im Webprojekt mit Nuget-Paketen lösen

3
Carolina

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

3
joelmdev

Wenn Sie Änderungen an Paketen vorgenommen haben, öffnen Sie das sln erneut. Das hat für mich funktioniert!

2
Naumaan Shaikh

VS 2017, MVC-Projekt

Ich weiß nicht warum, aber für mich bestand die Lösung für dieses Problem darin, einen out -Parameter aus einer Modellmethodensignatur zu entfernen, die von der Controller-Aktionsmethode aufgerufen wurde. das ist sehr seltsam Verhalten, aber das war die Lösung für mein Problem.

1
jonathana

Ich habe herausgefunden, dass manchmal Nuget-Pakete installiert werden (was ich vermute,) von .NET Core benötigte 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 Verweise zu entfernen. Zum Beispiel werden System.IO, System.Threading und dergleichen normalerweise hinzugefügt, wenn Microsoft.Bcl über ein kürzlich installiertes NuGet-Paket eingefügt wird. Es gibt keinen Grund für bestimmte Versionen dieser Projekte in meinen Projekten. Daher entferne ich die Verweise und die Projekterstellungen. Hoffentlich hilft das.

Sie können Ihre Projektdatei nach "Referenz" durchsuchen und die Konflikte entfernen. 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 vergewissere mich, dass Sie wissen, was für mich funktioniert hat :)

Beispiel für das, was ich kommentiert 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
Auri Rahimzadeh

Ich habe Microsoft ASP.NET MVC nuget.org von NuGet Packagaes aus deinstalliert und erneut installiert. Bei der Neuinstallation wurden alle Konflikte im Zusammenhang mit der Rasiermesser-Version behoben. Versuch es .

0
jitendra r

Ich bin gerade in dieses und das Problem gestoßen, nachdem ich ein Paket von nuget zu lokal referenzierten dlls gewechselt habe. Das Problem bestand in alten Laufzeitbindungen in app.config.

0
Tom Makin

Ich folgte dem Rat mehrerer Antworten hier, um herauszufinden, was falsch war, aber keine der Antworten schien zu erklären, wie man das Problem behebt. Mein Problem war, dass eine Referenz eine andere Version einer zweiten Referenz erforderte. Also war Newtonsoft bei Version 6, aber einige andere DLL wollten 4.5. Dann habe ich Newtonsoft aktualisiert, wie eine der anderen Antworten vorschlug, und das machte die Sache noch schlimmer.

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

Klicken Sie im Projektmappen-Explorer mit der rechten Maustaste auf "Verweise" und wählen Sie "NuGet-Pakete verwalten". Suchen Sie auf der Registerkarte "Installiert" nach "Newtonsoft" (oder was auch immer Ihr Konflikt ist) Versionen. Mir war nicht klar, dass dieses Dropdown zum Downgrade verwendet werden kann.

0
Andrew

Ich habe die MSBuild-Ausführlichkeit in Diagnostic geändert. Aber ich konnte nicht herausfinden, wo das Problem lag. Nach 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 die erste Systemversion von 4.0.0.0 auf 12.0.0.0 geändert und mein Projekt hat funktioniert.

Setzen Sie die Ausgabeprotokollierung wie bei den anderen Antworten auf "detailiert" und suchen Sie dort nach Konflikten, die Ihnen sagen, wo Sie als Nächstes suchen müssen.

In meinem Fall schickte ich mich in einige Richtungen auf die Suche nach der Quelle der Referenzen, aber am Ende stellte sich heraus, dass das Problem eines meiner tragbaren Klassenbibliothekprojekte war, es zielte auf die falsche Version und zog seine eigene an Version der Referenzen in, daher die Konflikte. Ein schnelles erneutes Ziel und das Problem wurde gelöst.

0
car1bo

Führen Sie den Befehl Update-Package über die Package Manager Console aus

Dies behebt MSB3277, wodurch es alle Pakete und alle zugehörigen Assemblys neu installiert, die mit der höchsten Version geliefert werden. 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 ein paar Mal behoben. Abhängig von der Anzahl der Nuget-Pakete kann dieser Vorgang einige Minuten dauern.

Weitere Informationen zu offiziellen Dokumenten https://docs.Microsoft.com/de-de/nuget/consume-packages/reinstalling-und-updating-packages

Diese Warnung hatte ich nach der Migration zur Paketreferenz. In der Diagnoseausgabe wurde angegeben, dass die Bibliothek von derselben Bibliothek selbst referenziert wurde. Es könnte ein Fehler in der neuen Paketreferenz sein. Die Lösung bestand darin, AutoGenerateBindingRedirects zu aktivieren und benutzerdefinierte Bindungsumleitungen zu löschen.

0
raV720