Freigeben über

NuGet-Warnung NU1605

  • Artikel

Beispiel 1

Paketdowngrade erkannt: 'PackageB' von 4.0.0 auf 3.5.0. Verweisen Sie direkt aus dem Projekt auf das Paket, um eine andere Version auszuwählen.
    'Project' -> 'PackageA' 4.0.0 -> 'PackageB' (>= 4.0.0)
    'Project' -> 'PackageB' (>= 3.5.0)

Problem

Ein Abhängigkeitspaket hat eine Versionseinschränkung für eine höhere Version eines Pakets angegeben, als die Wiederherstellung letztendlich aufgelöst wurde. Das liegt daran, dass die Direct-Dependency-wins-Regel - beim Auflösen von Paketen überschreibt die direkte Paketversion im Untergraphen die der entfernten Pakete mit derselben ID.

Lösung

Fügen Sie dem Projekt, das die Wiederherstellungswarnung anzeigt, einen Paketverweis auf die höhere Version des Pakets hinzu.

Im obigen Beispiel ändern Sie den Paketverweis auf PackageB 4.0.0:

'PackageA' 4.0.0 -> 'PackageB' 4.0.0
'PackageB' 4.0.0

Beispiel 2

Paketdowngrade erkannt: 'PackageC' von 2.0.0 auf 1.1.0. Verweisen Sie direkt aus dem Projekt auf das Paket, um eine andere Version auszuwählen.
    'Project' -> 'PackageA' 1.0.0 -> 'PackageB' 2.0.0 ->'PackageC' (>= 2.0.0)
    'Project' -> 'PackageA' 1.0.0 -> 'PackageC' (>= 1.1.0)

Problem

Ein Abhängigkeitspaket hat eine Versionseinschränkung für eine höhere Version eines Pakets angegeben, als die Wiederherstellung letztendlich aufgelöst wurde. Das liegt an der Regel für direkte Abhängigkeiten – beim Auflösen von Paketen versucht NuGet, die Absicht des Paketautors zu berücksichtigen. Der Autor von PackageA hat explizit auf PackageC 1.1.0 von PackageC 2.0.0 herabgestuft.

Lösung

Fügen Sie dem Projekt, das die Wiederherstellungswarnung anzeigt, einen Paketverweis auf die höhere Version des Pakets hinzu.

Im obigen Beispiel ändern Sie den Paketverweis auf PackageC 2.0.0:

'PackageA' 4.0.0 -> 'PackageB' 4.0.0
'PackageB' 4.0.0

Beispiel 3

Paketdowngrade erkannt: System.IO.FileSystem.Primitives von 4.3.0 auf 4.0.1. Verweisen Sie direkt aus dem Projekt auf das Paket, um eine andere Version auszuwählen.
Project -> System.IO.FileSystem 4.0.1 -> runtime.win.System.IO.FileSystem 4.3.0 -> System.IO.FileSystem.Primitives (>= 4.3.0)
Projekt -> System.IO.FileSystem 4.0.1 -> System.IO.FileSystem.Primitives (>= 4.0.1)

Problem

Bestimmte Kombinationen von Paketen, die mit .NET Core 1.0 und 1.1 ausgeliefert wurden, sind nicht miteinander kompatibel, wenn sie in einem .NET Core 3.0- oder höheren Projekt miteinander referenziert werden und ein RuntimeIdentifier angegeben wird. Die problematischen Pakete beginnen in der Regel mit System. oder Microsoft., und weisen Versionsnummern zwischen 4.0.0 und 4.3.1 auf. In diesem Fall verfügt die Downgradenachricht über ein Paket, das mit runtime.<RID> der Abhängigkeitskette beginnt.

Lösung

Um dieses Problem zu umgehen, fügen Sie das folgende PackageReference hinzu:

<PackageReference Include="Microsoft.NETCore.Targets" Version="3.0.0" PrivateAssets="all" />

Sie können wählen, ob sie die version entsprechende Hauptversion Ihres SDK verwenden möchten.

Beispiel 4

Paketdowngrade erkannt: Microsoft.NETCore.App von 2.1.8 auf 2.1.0. Verweisen Sie direkt aus dem Projekt auf das Paket, um eine andere Version auszuwählen.
    test -> mvc -> Microsoft.NETCore.App (>= 2.1.8)
    test -> Microsoft.NETCore.App (>= 2.1.0)

Problem

Das mvc-Projekt hat eine Versionseinschränkung für eine höhere Version eines Pakets angegeben, als die Wiederherstellung letztendlich aufgelöst wurde. Das liegt daran, dass die Direct-Dependency-wins-Regel - beim Auflösen von Paketen die Version des direkt referenzierten Pakets im Diagramm überschreibt die version des entfernten Pakets mit derselben ID.

Lösung

Dieser spezifische Fehler (mit Microsoft.NETCore.App Paket) wird verbessert, indem Das .NET Core SDK auf 2.2.100 oder höher verschoben wird. Microsoft.NETCore.App ist ein automatisch referenziertes Paket, das vom .NET Core SDK vor Version 3.0.100 automatisch eingefügt werden soll. Siehe auch Vorwärtsrollen der eigenständigen Bereitstellungslaufzeit.

Hinweis

Während NU1605 als Warnung durch das NuGet-Tool betrachtet wird, wird diese Warnung vom .NET SDK als Fehler WarningsAsErrorsbehandelt. Ihr Projekt kann diese Warnung in einen Fehler umwandeln, indem Sie TreatWarningsAsErrors auf true setzen. Es wird zwar nicht empfohlen, da es wahrscheinlicher ist, dass Laufzeitprobleme auftreten, sie können diese Warnung unterdrücken .

Tipp

Alternative Lösung: NuGetSolver ist eine von Microsoft DevLabs entwickelte Visual Studio-Erweiterung, die bei der Auflösung von Abhängigkeitskonflikten helfen soll. Sie automatisiert den Prozess der Identifizierung und Behebung dieser Probleme. Weitere Details finden Sie auf der NuGetSolver-Seite auf dem Visual Studio Marketplace und wir freuen uns, Ihr Feedback zu Ihrer Erfahrung zu hören.