Clearing the NuGet cache

NuGet is the package manager used by .NET to download, restore, and manage package dependencies. Most of the time it works quietly in the background: you add a package, restore the project, and NuGet downloads what is needed.

However, NuGet also stores packages and metadata locally. This is good for performance, because the same package does not need to be downloaded again and again. Over time, though, these local caches can grow large or occasionally contain stale data that interferes with package restore.

Clearing the NuGet cache is therefore useful in two common situations:

• you want to reclaim disk space;
• you are troubleshooting restore, build, or package update problems.

The easiest way to clear everything is:

dotnet nuget locals all --clear

This command clears all local NuGet resources managed by the .NET SDK.

What NuGet stores locally

NuGet does not have just one cache. It uses several local folders for different purposes:

Cache location	Purpose
global-packages	Stores the actual package contents used by projects.
http-cache	Stores downloaded package metadata and HTTP responses.
temp	Stores temporary files used during restore and install operations.
plugins-cache	Stores data used by NuGet credential provider plugins and related extensions.

When you run:

dotnet nuget locals all --clear

NuGet clears all of these locations.

That is usually the right command when you are troubleshooting a strange package restore issue and do not want to spend time guessing which cache is involved.

Listing the NuGet cache locations

Before clearing anything, you can ask NuGet where the local caches are stored:

dotnet nuget locals all --list

Typical output on Windows looks similar to this:

http-cache: C:\Users\<user>\AppData\Local\NuGet\v3-cache
global-packages: C:\Users\<user>\.nuget\packages\
temp: C:\Users\<user>\AppData\Local\Temp\NuGetScratch
plugins-cache: C:\Users\<user>\AppData\Local\NuGet\plugins-cache

The exact paths depend on the operating system, user profile, environment variables, and NuGet configuration.

This command is also useful when you want to inspect how much disk space NuGet is using before deleting anything.

Clearing all NuGet caches

To clear all NuGet caches with the .NET CLI, run:

dotnet nuget locals all --clear

Example output:

Clearing NuGet HTTP cache: C:\Users\Admin\AppData\Local\NuGet\v3-cache
Clearing NuGet global packages folder: C:\Users\Admin\.nuget\packages\
Clearing NuGet Temp cache: C:\Users\Admin\AppData\Local\Temp\NuGetScratch
Clearing NuGet plugins cache: C:\Users\Admin\AppData\Local\NuGet\plugins-cache
Local resources cleared.

After clearing the cache, the next restore may take longer because NuGet needs to download packages again:

dotnet restore

This is expected. Once the packages are restored again, subsequent builds should return to normal speed.

Clearing only one NuGet cache

You do not always need to clear everything. NuGet allows you to clear a specific cache location.

To clear only the HTTP cache:

dotnet nuget locals http-cache --clear

To clear only the global packages folder:

dotnet nuget locals global-packages --clear

To clear only the temporary NuGet cache:

dotnet nuget locals temp --clear

To clear only the plugins cache:

dotnet nuget locals plugins-cache --clear

Clearing only the HTTP cache is often enough when NuGet appears to be using stale package metadata. Clearing the global packages folder is more aggressive because it removes the actual packages already downloaded on the machine.

Using nuget.exe instead of dotnet

If you are using nuget.exe, the equivalent command is:

nuget locals all -clear

The syntax is slightly different:

dotnet nuget locals all --clear
nuget locals all -clear

Both commands are valid, but the dotnet version is usually the most convenient choice for modern SDK-style .NET projects.

Clearing the NuGet cache from Visual Studio

Visual Studio can also clear NuGet local resources without using the command line.

Open:

Tools > NuGet Package Manager > Package Manager Settings

Then go to the general NuGet settings page and select:

Clear NuGet local resources

This is useful when you are already working inside Visual Studio and want a quick way to reset NuGet local state.

However, I still prefer the command line when diagnosing build problems, because it is explicit, repeatable, and easy to include in troubleshooting notes.

When clearing the cache helps

Clearing the NuGet cache can help in cases such as:

• a package restore keeps failing even though the package exists;
• Visual Studio or dotnet restore appears to use old package metadata;
• a package was republished or changed on an internal feed;
• a private package feed had authentication problems;
• a build server has a corrupted local package cache;
• your disk is running low on space;
• switching between different feeds, branches, or package versions produces unexpected restore behavior.

It is not a magic fix for every NuGet problem, but it is a safe and practical first step when package restore behaves inconsistently.

Common troubleshooting problems

Files are in use

If clearing the cache fails with a message saying that a file is being used by another process, close applications that may be using NuGet packages.

Common processes include:

• Visual Studio;
• JetBrains Rider;
• VS Code;
• running dotnet processes;
• test runners;
• build tools;
• background language servers.

After closing them, run the command again:

dotnet nuget locals all --clear

Access denied

If NuGet reports an access denied error, the current user may not have permission to delete some files in the cache.

This can happen when:

• packages were restored by another user;
• a build ran with elevated permissions;
• files are owned by a service account;
• antivirus or security software is locking the folder.

In that case, close related processes and try again from a terminal with the appropriate permissions.

Restore is slow after clearing the cache

This is normal. Clearing the global packages folder removes the locally downloaded packages, so the next restore must download them again.

Run:

dotnet restore

After the restore completes, normal incremental build performance should return.

The problem comes back immediately

If the same restore issue comes back after clearing the cache, the root cause may not be the cache itself.

Check:

• the package version referenced by the project;
• NuGet.config;
• configured package sources;
• credentials for private feeds;
• network or proxy settings;
• whether the package exists on the selected feed;
• whether the project uses packages.config or PackageReference;
• whether multiple feeds contain different packages with the same ID and version.

Clearing the cache removes local state, but it does not fix incorrect package source configuration.

A useful reset sequence

When NuGet restore behaves strangely, this is the reset sequence I usually try first:

dotnet nuget locals all --clear
dotnet restore
dotnet build

For a solution file:

dotnet nuget locals all --clear
dotnet restore MySolution.sln
dotnet build MySolution.sln

For a specific project:

dotnet nuget locals all --clear
dotnet restore MyProject.csproj
dotnet build MyProject.csproj

This gives you a clean local NuGet state and verifies that the project can restore and build from the configured package sources.

Should you delete the cache manually?

You can manually delete NuGet cache folders, but it is better to use the official command:

dotnet nuget locals all --clear

The command knows the NuGet cache locations and clears them consistently. It also avoids depending on hard-coded paths that may differ between machines, operating systems, users, and build environments.

Manual deletion is best reserved for unusual cases where the official command cannot remove a specific locked or corrupted folder.

Clearing NuGet cache on build agents

On build agents, clearing the NuGet cache can solve corrupted-cache problems, but it should not be done blindly on every build.

Package caches improve build performance. If you clear them too often, every build will spend more time downloading dependencies.

A reasonable approach is:

• keep the cache during normal builds;
• clear it only when diagnosing restore problems;
• clear it when changing package source configuration;
• clear it when a build agent has a known corrupted cache;
• use proper package lock files and repeatable restore settings where appropriate.

For continuous integration, cache invalidation should be deliberate. A clean cache is useful for troubleshooting, but a warm cache is useful for performance.

Summary

Clearing the NuGet cache is a simple but effective way to solve many package restore problems and reclaim disk space.

The most useful command is:

dotnet nuget locals all --clear

To see where NuGet stores its local files, use:

dotnet nuget locals all --list

After clearing the cache, restore the project again:

dotnet restore

For most modern .NET projects, these commands are the fastest way to reset NuGet local state and make sure packages are downloaded again from the configured package sources.