Introduction

NU1605 means NuGet detected that one part of your project graph wants a newer package version while another reference path forces an older one. In practice, this usually happens when a project directly references an older package version that conflicts with a newer transitive dependency.

What NU1605 Is Actually Telling You

A typical downgrade scenario looks like this:

• package A depends on B version 5.0.0
• your project directly references B version 4.0.0
• NuGet warns or fails because the resolved version would downgrade what A expects

That is why the message mentions a detected package downgrade rather than a missing package.

A Simple Example

Suppose your project file contains:

1<ItemGroup>
2  <PackageReference Include="PackageA" Version="3.2.0" />
3  <PackageReference Include="PackageB" Version="4.0.0" />
4</ItemGroup>

But PackageA depends on PackageB >= 5.0.0. NuGet will complain because the explicit 4.0.0 reference forces an older version into the graph.

The Most Common Fix: Upgrade the Direct Reference

Usually the correct fix is to align the direct reference with the higher required version.

1<ItemGroup>
2  <PackageReference Include="PackageA" Version="3.2.0" />
3  <PackageReference Include="PackageB" Version="5.0.0" />
4</ItemGroup>

This resolves the downgrade by letting the graph use a compatible version for both the direct and transitive paths.

Inspect the Dependency Graph Before Guessing

Do not change versions blindly. Inspect the graph first.

Useful commands:

dotnet list package

And for transitive dependencies:

dotnet list package --include-transitive

These commands help you see:

• which package is direct versus transitive
• which version is currently resolved
• where the conflicting version comes from

That is often enough to identify the exact package that needs adjustment.

Solutions Depend on Where the Conflict Comes From

Common resolutions include:

• upgrade the lower direct reference
• remove an unnecessary direct reference and let the transitive version win
• upgrade the top-level package bringing in the outdated dependency chain
• align package versions across multiple projects in the solution

The right fix depends on which package should actually control the version.

Multi-Project Solutions Often Need Version Alignment

In a solution with several projects, NU1605 often means one project references a different version from the others.

For example:

• 'ProjectA uses Newtonsoft.Json 13.x'
• 'ProjectB uses Newtonsoft.Json 12.x'
• a consuming app references both

Even if each project builds alone, the combined solution can surface downgrade conflicts. Centralizing versions or reviewing shared dependencies usually fixes this class of problem more cleanly than patching one .csproj at a time.

Central Package Management Can Help

If you use central package management, keep shared versions in one place instead of scattering them across many project files.

Example Directory.Packages.props:

1<Project>
2  <ItemGroup>
3    <PackageVersion Include="Newtonsoft.Json" Version="13.0.3" />
4  </ItemGroup>
5</Project>

This makes version drift less likely and reduces surprise downgrade conflicts in larger solutions.

Be Careful with Suppression

It is possible to suppress warnings, but that is usually the wrong first move. NU1605 often signals a real compatibility problem. If you suppress it without understanding the graph, the build may succeed while runtime behavior becomes fragile or inconsistent.

Treat suppression as the last resort, not the first fix.

Clean Restore After Fixing Versions

After adjusting package references, restore again so the lock state and asset graph are rebuilt cleanly.

dotnet restore

If the project still behaves strangely, clearing local caches can help in rare cases:

dotnet nuget locals all --clear

But cache clearing is not the actual fix. Version alignment is.

Common Pitfalls

• Fixing NU1605 by guessing a version instead of inspecting the dependency graph first.
• Keeping an unnecessary direct reference that forces an older package version than a dependency needs.
• Treating the warning as harmless and suppressing it without understanding the compatibility risk.
• Forgetting that multi-project solutions can introduce version conflicts even when each project builds individually.
• Solving the issue in one project while leaving inconsistent package versions elsewhere in the solution.

Summary

• NU1605 means NuGet detected a package version downgrade in the dependency graph.
• The most common fix is to align the direct package reference with the higher required version.
• Use dotnet list package --include-transitive to inspect the real dependency path before changing anything.
• In larger solutions, centralizing package versions often prevents recurring downgrade issues.
• Suppressing the warning is usually a poor substitute for actually fixing the version mismatch.