Breyta

Deila með

NuGet Warning NU1605

  • Grein

Example 1

Detected package downgrade: 'PackageB' from 4.0.0 to 3.5.0. Reference the package directly from the project to select a different version.
    'Project' -> 'PackageA' 4.0.0 -> 'PackageB' (>= 4.0.0)
    'Project' -> 'PackageB' (>= 3.5.0)

Issue

A dependency package specified a version constraint on a higher version of a package than restore ultimately resolved. That is because of the direct-dependency-wins rule - when resolving packages, the direct package version in the subgraph will override that of the distant packages with the same ID.

Solution

To the project exhibiting the restore warning, add a package reference to the higher version of the package.

In the example above, you would change the package reference to PackageB 4.0.0:

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

Example 2

Detected package downgrade: 'PackageC' from 2.0.0 to 1.1.0. Reference the package directly from the project to select a different version.
    'Project' -> 'PackageA' 1.0.0 -> 'PackageB' 2.0.0 ->'PackageC' (>= 2.0.0)
    'Project' -> 'PackageA' 1.0.0 -> 'PackageC' (>= 1.1.0)

Issue

A dependency package specified a version constraint on a higher version of a package than restore ultimately resolved. That is because of the direct-dependency-wins rule - when resolving packages, NuGet tries to honor the intent of the package author. The author of PackageA has explicitly downgraded to PackageC 1.1.0 from PackageC 2.0.0.

Solution

To the project exhibiting the restore warning, add a package reference to the higher version of the package.

In the example above, you would change the package reference to PackageC 2.0.0:

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

Example 3

Detected package downgrade: System.IO.FileSystem.Primitives from 4.3.0 to 4.0.1. Reference the package directly from the project to select a different version.
    Project -> System.IO.FileSystem 4.0.1 -> runtime.win.System.IO.FileSystem 4.3.0 -> System.IO.FileSystem.Primitives (>= 4.3.0)
    Project -> System.IO.FileSystem 4.0.1 -> System.IO.FileSystem.Primitives (>= 4.0.1)

Issue

Certain combinations of packages which shipped with .NET Core 1.0 and 1.1 are not compatible with each other when they are referenced together in a .NET Core 3.0 or higher project, and a RuntimeIdentifier is specified. The problematic packages generally start with System. or Microsoft., and have version numbers between 4.0.0 and 4.3.1. In this case, the downgrade message will have a package starting with runtime.<RID> in the dependency chain.

Solution

To work around this issue, add the following PackageReference:

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

You may choose to use the version matching the the major version of your SDK.

Example 4

Detected package downgrade: Microsoft.NETCore.App from 2.1.8 to 2.1.0. Reference the package directly from the project to select a different version.
    test -> mvc -> Microsoft.NETCore.App (>= 2.1.8)
    test -> Microsoft.NETCore.App (>= 2.1.0)

Issue

The mvc project specified a version constraint on a higher version of a package than restore ultimately resolved. That is because of the direct-dependency-wins rule - when resolving packages, the version of directly referenced package in the graph will override that of the distant package with the same ID.

Solution

This specific error (with Microsoft.NETCore.App package) is improved by moving your .NET Core SDK to 2.2.100 or later. Microsoft.NETCore.App is an auto-referenced package that the .NET Core SDK before version 3.0.100 chooses to bring in automatically. Also see Self-contained deployment runtime roll forward.

Note

While NU1605 is considered a warning by the NuGet tooling, the .NET SDK opts into treating this warning as an error through WarningsAsErrors. Your project may be upgrading this warning to an error by setting TreatWarningsAsErrors to true. While not recommended, as you are more likely to encounter runtime issues, you may choose to suppress this warning.

Tip

Alternative solution: NuGetSolver is a Visual Studio Extension developed by Microsoft DevLabs, designed to assist in resolving dependency conflicts. It automates the process of identifying and addressing these issues. For further details, visit the NuGetSolver page on the Visual Studio Marketplace and we'd love to hear your feedback about your experience.