Why NuGet Keeps Downgrading "Floating" Versions

Author Lee Timmins Date 9th Jan 2026 Comments Comments

If you use floating versions in your .csproj (e.g., Version="1.*"), you may have seen an issue where you restore the latest version via the CLI, but as soon as you click Build in Visual Studio, it reverts to an older version.

The Problem: The 30-Minute Cache

NuGet is designed to stay fast by not hitting the network on every build. When you use a wildcard version, NuGet caches the "latest available version" metadata locally.

Running dotnet restore --no-cache forces a one-time check to the server, which bypasses the cache. However, Visual Studio’s still uses the standard cache. If that 30-minute window hasn't closed, VS will see the old version in its cache and "fix" your project by downgrading it back to the older version.

The Fix: Clear the HTTP Cache

You don't have to wait 30 minutes for the cache to expire. You can force NuGet to forget the old version list immediately by running:

dotnet nuget locals http-cache --clear

Azure Publish Issue: Stale Packages Still Being Used

Even if restore succeeds and the correct version appears in the CLI, you may still see the wrong DLL version when publishing to Azure App Service from Visual Studio.

This happens because NuGet also uses the global packages folder, which stores the actual extracted package contents (DLLs and build assets), typically located at:

~/.nuget/packages

If a package version already exists in this folder, NuGet may reuse it instead of re-downloading it, even if the feed has changed or been republished. This can result in Visual Studio and Azure deployments using an outdated assembly.

The Fix for Azure Deployments

To ensure a clean and correct deployment, clear the global packages cache before publishing:

dotnet nuget locals global-packages --clear

Then run a fresh restore and publish:

dotnet restore
dotnet publish

Full Cache Reset (Most Aggressive Option)

If you're debugging persistent or inconsistent package resolution issues, you can clear all NuGet caches at once:

dotnet nuget locals all --clear

This removes HTTP cache, global packages, and other local NuGet caches. It guarantees a completely fresh restore, but the next build will be slower because all dependencies must be re-downloaded.

Summary

  • HTTP cache controls package version metadata (what versions exist)
  • Global packages cache controls actual DLLs and build assets (what gets compiled and deployed)
  • Visual Studio and Azure publish can reuse cached package outputs even after a successful restore

For most issues, clearing just the HTTP cache or global packages is enough. Use dotnet nuget locals all --clear only when you need a full reset.