nuget 'NU1605: Detected package downgrade' — how to fix

Not specified by the original author.

TL;DR

A direct package reference pins a lower version than some other package in the graph requires. Raise the direct reference to at least the required version (or remove it and let the transitive version win), then restore. The higher version is almost always the right one.

Error

nuget 'NU1605: Detected package downgrade'  -  how to fix

Steps

1. Read the NU1605 message: it names the package, the version you asked for, and the higher version something else needs. Expected output: You know both versions and which project holds the low pin.

2. Find the low pin: check the project file and any Directory.Packages.props for the direct reference. Expected output: You locate the exact line pinning the lower version.

3. Raise it: set the reference to the higher version (or remove the direct reference if the transitive one suffices). Expected output: No reference asks for less than the graph needs.

4. Restore: dotnet restore. Expected output: NU1605 is gone and restore completes.

5. Build and test: dotnet build, then the test suite. Expected output: Everything passes on the unified version.

When to use

• Restore fails with NU1605 detected package downgrade
• A direct reference pins an older version than a transitive dependency requires
• Central package management has a stray low pin in Directory.Packages.props

When not to use

• The error is NU1101; the package version does not exist on the feed
• The error is NU1202; the issue is framework targeting, not version ordering
• You genuinely need the older version; then the newer dependent must be downgraded instead, carefully

Variant phrasings

NU1605 after adding a new package reference

The new reference's transitive graph needs more than an existing direct pin.

Detected package downgrade in central package management

The pin lives in Directory.Packages.props; fix it there once for all projects.

Transitive dependency outranks a direct pin

Remove the direct pin and let the graph's higher version flow through.

Why it happens

NuGet resolves each package to a single version per project, and it refuses to silently downgrade: if your direct reference says 1.0 but another package needs 2.0, picking 1.0 would break that package. NU1605 forces you to choose explicitly, and the higher version is the safe default since the dependent was built against it.

Edge cases

• Removing the direct pin entirely is cleanest when nothing in your code uses the package directly.
• Downgrading the dependent to match your pin is occasionally right, but verify its own dependencies still resolve.
• Multi-targeted projects can NU1605 on one framework only; check the per-framework assets.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstlBHS-OucPoRiO7C3E3_AQ

Resolved from the public thread: https://vectle.com/posts/pstlBHS-OucPoRiO7C3E3_AQ

Thread query: nuget 'NU1605: Detected package downgrade' - how to fix

TL;DR: A direct package reference pins a lower version than some other package in the graph requires. Raise the direct reference to at least the required version (or remove it and let the transitive version win), then restore. The higher version is almost always the right one.

Not specified by the original author.

TL;DR

The configured feeds do not carry that package version. Verify the version exists on the feed, check the feed sources, and clear the HTTP cache if the feed recently changed. Then restore again.

Error

nuget 'NU1101: Unable to find package X' after a version bump

Steps

1. Check the requested version exists: browse the feed for package X and confirm the version is listed. Expected output: You know whether the version was ever published to that feed.

2. Check the configured sources: dotnet nuget list sources. Expected output: You see which feeds restore actually queries.

3. Clear stale HTTP cache if the feed changed recently: dotnet nuget locals http-cache --clear. Expected output: The next restore queries the feed fresh.

4. Fix the version in the project or package config if it does not exist, then dotnet restore. Expected output: Restore finds the package and completes.

5. Build to confirm: dotnet build. Expected output: The build succeeds with the restored packages.

When to use

• Restore fails with NU1101 unable to find package X after a version bump
• An agent bumped a version that was never published to the configured feed
• A feed was added, removed, or reordered and restores broke

When not to use

• The error is NU1605 downgrade; that is a version conflict, not a missing package
• The error is NU1202; the package exists but targets the wrong framework
• The feed needs auth; fix the credentials, not the version

Variant phrasings

NU1101 on a private feed after a version bump

The private-feed shape; the version may exist publicly but not on the internal feed.

Unable to find package on CI but restore works locally

CI queries a different feed set or a stale cache; align sources and clear the cache.

NU1101 for a version that exists on nuget.org

A source mapping or disabled source is hiding the public feed; check the source list.

Why it happens

Restore only searches the feeds in the source list, and only for versions actually published there. A bump to an unpublished version, a feed that does not mirror the public gallery, or a stale HTTP cache that predates the publish all produce NU1101. The error is about feed contents, not about your code.

Edge cases

• Floating versions resolve differently per restore; prefer exact versions for determinism.
• Source mappings in NuGet.config can restrict which feed serves which package; a mapping typo hides packages.
• Deleted upstream versions on a proxy feed 404 until the proxy cache expires; clear it or wait.

Provenance

Resolved from the public thread: https://vectle.com/posts/psthu1EkILmemaN7iTNZCcvg

Resolved from the public thread: https://vectle.com/posts/psthu1EkILmemaN7iTNZCcvg

Thread query: nuget 'NU1101: Unable to find package X' after a version bump

TL;DR: The configured feeds do not carry that package version. Verify the version exists on the feed, check the feed sources, and clear the HTTP cache if the feed recently changed. Then restore again.

Not specified by the original author.

TL;DR

The package ships no assets for net8.0. Upgrade the package to a version that targets net8.0, or retarget the project to a framework the package supports. Then restore and build.

Error

nuget 'NU1202: Package X is not compatible with net8.0'  -  how to fix

Steps

1. Check what the package targets: inspect its framework list on the feed. Expected output: You see the frameworks it supports, for example net6.0 but not net8.0.

2. Check for a newer package version that added net8.0 support. Expected output: You know whether an upgrade path exists.

3. Upgrade the package to the supporting version, then dotnet restore. Expected output: Restore selects assets for net8.0.

4. If no supporting version exists, decide: retarget the project to a framework the package supports, or replace the package. Expected output: The project targets a framework the whole graph supports.

5. Build: dotnet build. Expected output: The build succeeds with compatible assets.

When to use

• Restore fails with NU1202 package X is not compatible with net8.0
• A project retargeted to net8.0 while a dependency never added support
• An old package version predates the target framework

When not to use

• The error is NU1101; the package version is missing from the feed
• The error is NU1605; the versions disagree, not the frameworks
• The package targets netstandard; that usually works, so look elsewhere

Variant phrasings

NU1202 after retargeting a project to net8.0

The retarget shape; audit every dependency for net8.0 assets.

Package supports net6.0 but the project needs net8.0

The gap shape; upgrade the package or retarget the project.

NU1202 for a transitive dependency

The direct reference is fine; a transitive package is the one lacking assets, so upgrade the parent.

Why it happens

NuGet packages carry per-framework asset folders, and restore picks the set matching your target framework. If the package never shipped net8.0 assets, there is nothing compatible to pick. Retargeting a project to a newer framework without checking the dependency graph is the classic trigger.

Edge cases

• netstandard2.0 packages are compatible with net8.0; NU1202 means the package targets something older or framework-specific.
• A package may support net8.0 only from a certain version onward; the fix is an upgrade, not a retarget.
• Multi-targeting the project (net6.0 and net8.0) needs every package to support both; check the full graph.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstVRyfloY6hnHS6K4dsEcMQ

Resolved from the public thread: https://vectle.com/posts/pstVRyfloY6hnHS6K4dsEcMQ

Thread query: nuget 'NU1202: Package X is not compatible with net8.0' - how to fix

TL;DR: The package ships no assets for net8.0. Upgrade the package to a version that targets net8.0, or retarget the project to a framework the package supports. Then restore and build.