.net - tutorial - use msbuild engine




Gefundene Konflikte zwischen verschiedenen Versionen derselben abhängigen Assembly, die nicht aufgelöst werden konnten (11)

Wenn ich meine Lösung säubere und dann erstelle, die mehrere Projekte enthält, meldet das Ausgabefenster, dass der Build erfolgreich war. Wenn ich das Fehlerlistenfenster jedoch anzeigen, zeigt es mir diese Warnung an:

Gefundene Konflikte zwischen verschiedenen Versionen derselben abhängigen Assembly, die nicht aufgelöst werden konnten. Diese Referenzkonflikte werden im Build-Protokoll aufgelistet, wenn die Protokoll-Ausführlichkeit auf detailliert festgelegt 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 mit welcher DLL falsch ist und wie mache ich dann die Warnung weg?


und wie mache ich dann die Warnung weg?

Wahrscheinlich müssen Sie Ihre NuGet-Pakete reinstall oder aktualisieren, um dies zu beheben.


Das Ändern der Build-Ausführlichkeit im Visual Studio hilft dabei, in die richtige Richtung zu zeigen. Befolgen Sie die folgenden Schritte, um die Ausführlichkeit in VS zu ändern

1. Go to Tools->Options menu in VS
2. Open Projects and Solutions->Build and Run 
3. Change the value of the MSBuild project build output verbosity. 
   Pick one from Quiet, Minimal, Normal, Detailed and Diagnostic

Überprüfen Sie das Ausgabefenster (Strg + Alt + O) in VS für die Änderungen in Build


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

Das wird MSB3277 reparieren, was es tut, es installiert alle Pakete und alle damit verbundenen Assemblies mit der höchst möglichen Version neu . Es ist auch möglich, nur ein bestimmtes Paket zu aktualisieren. Oder Downgrade nach Update wenn gewünscht, dieses Problem behoben für mich einige Male kam es. Abhängig davon, 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


Ich bin gerade auf dieses Problem gestoßen, nachdem ich ein Paket von nugget auf lokal referenzierte DLLs umgestellt habe. Das Problem war altes Laufzeitbindungskram in app.config .


Ich habe die MSBuild-Ausführlichkeit in Diagnostic geändert. Aber ich konnte nicht finden, wo das Problem war, 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.


Ich habe festgestellt, dass nuget-Pakete manchmal installiert werden (was ich vermute). .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 Referenzen zu entfernen. System.IO, System.Threading usw. werden beispielsweise hinzugefügt, wenn Microsoft.Bcl in einem kürzlich installierten NuGet-Paket enthalten ist. Es gibt keinen Grund für bestimmte Versionen dieser in meinen Projekten, daher entferne ich die Referenzen und die Projekt-Builds. Ich hoffe, das hilft.

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 kann nicht alle Fälle dieses Problems beantworten - ich stelle sicher, dass Sie wissen, was für mich funktioniert hat :)

Beispiel dessen, 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> -->


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

und die Nachricht:

C: \ Programme (x86) \ MSBuild \ 12.0 \ bin \ Microsoft.Common.CurrentVersion.targets (1697,5): Warnung MSB3277: Konflikte zwischen verschiedenen Versionen derselben abhängigen Assembly gefunden, die nicht aufgelöst werden konnten. Diese Referenzkonflikte werden im Build-Protokoll aufgelistet, wenn die Protokoll-Ausführlichkeit auf detailliert festgelegt ist .

Also hat Ruben Recht - das ist einfach nicht wahr. Es gibt keine Konflikte, nur eine fehlende Assembly. 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 bevor sie zum ersten Mal angezeigt werden. In diesem Fall muss die Baugruppe verfügbar sein. (Es gibt eine Option zum Vorkompilieren der Ansichten zusammen mit dem Rest des Codes, aber das ist eine andere Geschichte .) Wenn Sie jedoch den Ausführlichkeitsgrad 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 konnte nicht gefunden werden "System.Web.Razor, Version = 3.0.0.0, Culture = neutral, PublicKeyToken = 31bf3856ad364e35, processorArchitecture = MSIL". Stellen Sie sicher, dass die Assembly auf der Festplatte vorhanden ist. Wenn dieser Verweis von Ihrem Code benötigt wird, können Sie Kompilierungsfehler erhalten.

Daher müssen Sie nur Folgendes tun:

  1. Fügen Sie manuell einen Verweis auf die Assembly hinzu (suchen Sie sie auf der Festplatte, vielleicht GAC, und fügen Sie sie als "direkte" Referenz 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 über NuGet Galerie here . Weitere Informationen zum Vorkompilieren von ASP.NET-Ansichten finden Sie here .


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), die zuvor direkt in unserem Webprojekt referenziert 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 für die Verwendung der von NuGet verwalteten Assembly wurde das Problem behoben.


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


Wie bei den anderen Antworten, stellen Sie den Ausgabe-Logging-Level auf detailliert ein und suchen Sie dort nach Konflikten, die Ihnen sagen, wohin Sie als nächstes schauen sollen.

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


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





visual-studio-express