What does nuget:NU1608 mean?

NuGet resolved a package version outside another package’s declared dependency range, and that mismatch may be treated as an error.

How do I prevent nuget:NU1608 in CI?

Update dependencies regularly to avoid upper-bound drift. Treat NU1608 as a signal to validate compatibility before ignoring it.

How can I manually validate nuget:NU1608?

Re-run the failing command and confirm the original code/message is gone. Confirm expected artifacts or outputs exist (packages restored, build/publish succeeds).

NU1608: Detected package version outside of dependency constraint

Fix it fast

Most likely: A direct dependency, transitive dependency, or central package version forced a package version outside another package's allowed range.

1. Confirm this is your error

warning NU1608: Detected package version outside of dependency constraint: PackageA requires PackageB (< 2.0.0) but version 2.1.0 was resolved.

2. Check the cause

dotnet restore -v normal
dotnet list package --include-transitive
grep -R -n "<PackageReference\|<PackageVersion" *.csproj Directory.Packages.props

3. Apply the safe fix

# Best fix: upgrade the package that owns the constraint so it supports the resolved dependency version.
dotnet add package <parent-package-id> --version <compatible-version>

# Or pin the dependency back inside the allowed range if the rest of the graph supports it.
dotnet restore
dotnet test

4. Verify it works

dotnet restore
dotnet list package --include-transitive
dotnet test

Don't use unsafe shortcuts

Do not suppress NU1608 until you know the resolved version is compatible with the package that declared the constraint.
Do not force a newer transitive version without checking the parent package's supported range.
Do not update tightly coupled package families one package at a time when their versions are meant to move together.

What Broke in the Dependency Graph

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

Upgrade the constrained package to one that supports the newer dependency version, which is usually the best fix.

Or pin the dependency back into the allowed range if it stays compatible with the rest of your graph.

Restore and test again:dotnet restore && dotnet test

Why Resolution Broke

Usually this comes down to another dependency forces a newer version beyond an upper bound, dependency constraints are outdated or too strict for newer major versions, or central version pinning overrides the constrained range.

Prove the Graph Is Clean Again

NU1608 no longer appears, or is intentionally suppressed with a tracked reason.

Tests cover the affected code paths with the resolved versions.

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).

Mechanism

Packages declare dependency ranges and NuGet tries to satisfy them. If the graph forces a version outside the range, it warns with NU1608 and that warning may be treated as an error.

Keep the Dependency Graph Healthy

To prevent this, update dependencies regularly to avoid upper-bound drift, and treat NU1608 as a signal to validate compatibility before ignoring it.

Docs and source code

NU1608 constraint violation message

Message template for a resolved version violating a constraint. - GitHub

  <data name="Warning_VersionAboveUpperBound" xml:space="preserve">
    <value>Detected package version outside of dependency constraint: {0} requires {1} but version {2} was resolved.</value>
  </data>
  <data name="SignCommandDisplayCertificate" xml:space="preserve">