Published on

NuGet Restore Fails After Publish? It's Probably Cached Feed Metadata.

Authors

The Problem

You publish a new package version.

The feed shows it. The version number is correct. The publish step succeeded.

Then a consuming project runs:

dotnet restore

And fails with:

NU1101: Unable to find package My.Package.

The version absolutely exists in the feed UI.

So what is happening?

In most cases: cached NuGet feed metadata.

This Is Not About Reusing Versions

Let's separate two different problems.

This post is not about:

  • Reusing a version number
  • Testing stale binaries
  • Forgetting to increment patch versions

You did bump the version. You did publish correctly.

The issue is that your local NuGet resolver has cached feed state that says:

"That version does not exist."

And it does not immediately re-evaluate that assumption.

What NuGet Actually Caches

NuGet caches more than package binaries.

It caches:

  • HTTP responses
  • Feed index data
  • Version metadata
  • Global package resolution state
  • Plugin authentication state

This is good. It makes restore fast and deterministic.

But in tight publish → consume loops, especially with private feeds, this can surface as:

  • Restore failing immediately after publish
  • Inconsistent behavior across machines
  • CI agent A succeeding, agent B failing
  • Docker builds not seeing new versions

The feed is correct.

The local resolver state is not.

Why Clearing Locals Works

When you run:

dotnet nuget locals all --clear

You clear:

  • http-cache
  • global-packages
  • temp
  • plugins-cache

Now restore is forced to query the feed again.

The version is discovered. Restore succeeds.

Nothing changed in the feed. Only the local resolution state changed.

Where This Shows Up Most Often

In practice, I see this in:

  • Multi-repository setups
  • Internal SDK / connector packages
  • Azure Artifacts feeds
  • Self-hosted CI agents
  • Docker builds with cached restore layers
  • Publishing and consuming within the same pipeline

The closer publish and restore happen in time, the more likely you are to hit this.

Debugging Checklist

When restore cannot find a version that clearly exists:

  1. Verify the exact version in the feed.

  2. Confirm the feed URL in nuget.config.

  3. Run:

    dotnet nuget locals all --clear

  4. Delete bin and obj.

  5. Run dotnet restore again.

If that fixes it, you were dealing with cached metadata.

If it does not, then investigate feed configuration or authentication.

Important Distinction

There are two separate NuGet failure modes:

1. Stale binary reuse

Same version number → old binary reused from ~/.nuget/packages.

2. Version not found after publish

Feed metadata cached → restore does not see newly published version.

This post is about #2.

And it is the one that makes you doubt your infrastructure when nothing is actually wrong.

Final Note

NuGet is deterministic within its cached state.

If you are working with private feeds and tight feedback loops, clearing locals is not a hack --- it is a legitimate debugging step.

When restore says a version does not exist, and you can see it in the feed, the first suspect should be cached metadata.