What Broke in the Dependency Graph
NuGet resolved a lower version than one dependency path requested, which may break assumptions and is often treated as an error.
This is NuGet refusing to continue with a dependency graph that does not make sense. The important detail is which versions or peer requirements disagree, not just the final error code.
Repair the dependency graph
Add or update an explicit PackageReference or PackageVersion to the intended higher version.
Upgrade parent packages so they converge on compatible transitive versions.
Re-run:dotnet restore && dotnet build
Why Resolution Broke
Usually this comes down to a direct reference pins an older version than a transitive requirement, CPM pins a version below another package’s requested minimum, or partial upgrades cause skew across package families.
Prove the Graph Is Clean Again
Restore and build complete without NU1605.
project.assets.json shows the expected resolved version.
Validation
Re-run the failing command and confirm the original code/message is gone, and confirm expected artifacts or outputs exist (packages restored, build/publish succeeds).
Examples
error NU1605: Detected package downgrade: Example.Package from 2.0.0 to 1.5.0. Reference the package directly from the project to select a different version.Mechanism
NuGet computes a single resolved version per package. If the resolved version is lower than a requested version elsewhere in the graph, it emits NU1605.
Keep the Dependency Graph Healthy
To prevent this, manage versions centrally with CPM and update regularly, and run restore and build for all TFMs in CI to catch skew early.
Docs and source code
NU1605 downgrade message
Message template and suggested fix via explicit reference. - GitHub
<data name="Log_DowngradeWarning" xml:space="preserve">
<value>Detected package downgrade: {0} from {1} to {2}. Reference the package directly from the project to select a different version.</value>
<comment>{0}: package id
{1}: requested version
{2}: resolved version</comment>
</data>