Managing the global packages, cache, and temp folders

Whenever you install, update, or restore a package, NuGet manages packages and package information in several folders outside of your project structure:

By using the cache and global-packages folders, NuGet generally avoids downloading packages that already exist on the computer, improving the performance of install, update, and restore operations. When using PackageReference, the global-packages folder also avoids keeping downloaded packages inside project folders, where they might be inadvertently added to source control, and reduces NuGet's overall impact on computer storage.

When asked to retrieve a package, NuGet first looks in the global-packages folder. If the exact version of package is not there, then NuGet checks all non-HTTP package sources. If the package is still not found, NuGet looks for the package in the http-cache unless you specify --no-http-cache with dotnet.exe commands or -NoHttpCache with nuget.exe commands. If the package is not in the cache, or the cache isn't used, NuGet then retrieves the package over HTTP .

For more information, see What happens when a package is installed?.

global-packages

The global-packages folder is where NuGet installs any downloaded package. Each package is fully expanded into a subfolder that matches the package identifier and version number. Projects using the PackageReference format always use packages directly from this folder. When using the packages.config, packages are installed to the global-packages folder, then copied into the project's packages folder.

Cleaning the global-packages directory

The global-packages directory needs to be manually cleaned to remove packages that are no longer used. You can do this with the dotnet nuget locals global-packages --clean command, or the "clear NuGet local resources" button in Visual Studio's options (equivalent to dotnet nuget locals all --clear). After clearing the global-packages directory, you will need to restore your projects again to redownload all required packages. In Visual Studio, you may need to reload your solution to clear NuGet's "up to date restores" cache, or alternatively do a command line restore (for example, within Visual Studio's terminal window) with msbuild -t:restore your.sln.

To clean only unused packages, it's a two step process. First, there is a nuget.config setting updatePackageLastAccessTime that should be enabled. This setting will cause NuGet to update each package's .nupkg.metadata file when it is used in a restore. When restore runs, but a project is considered already up to date, the package timestamps are not updated. The .nupkg.metadata file is the last file that NuGet will create when downloading and extracting packages during a restore or install, and is the file that restore uses to check if a package has been extracted successfully.

Second, run a tool to perform the cleanup. After the updatePackageLastAccessTime setting is enabled, we recommend waiting a few days to make sure that all the packages you use regularly have had their timestamps updated.

At this time, NuGet does not provide a tool or command to do this. You can add a 👍 reaction to this GitHub issue to signal your interest. Some community members have created their own open source NuGet cleaner tools that you can search for.

If you are going to write your own cleanup tool, it is important that the .nupkg.metadata file is deleted if any of the other package files are deleted, so we recommend that this file is deleted first. Otherwise projects referencing the package may have unexpected behavior. If writing a cleanup tool in .NET, consider using ConcurrencyUtilities.ExecuteWithFileLocked[Async](..) from the NuGet.Common package, passing the full nupkg path of the package directory you're going to delete as the key, to avoid deleting a package that restore is trying to extract at the same time. The global packages directory can be programatically found with the NuGet.Configuration package. Use Settings.LoadDefaultSettings(path) to get an ISettings instance (you can pass null as the path, or pass a directory if you want to handle solutions with a nuget.config that redirects the global-packages directory), and then use SettingsUtility.GetGlobalPackagesFolder(settings). Alternatively, you can run dotnet nuget locals global-packages --list as a child process and parse the output.

http-cache

NuGet will cache copies of most NuGet feed communications (excluding search), organized into subfolders for each package source. Packages are not expanded, and files with a last modified date older than 30 minutes are typically considered expired.

temp

A folder where NuGet may store temporary files during its various operations.

plugin-cache

A folder where NuGet stores the results from the operation claims request. See the cross platform plugins reference for more information.

Viewing folder locations

You can view locations using the nuget locals command:

# Display locals for all folders: global-packages, http cache, temp and plugins cache
nuget locals all -list

Typical output (Windows; "user1" is the current username):

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

(package-cache is used in NuGet 2.x and appears with NuGet 3.5 and earlier.)

You can also view folder locations using the dotnet nuget locals command:

dotnet nuget locals all --list

Typical output (Mac; "user1" is the current username):

info : http-cache: /home/user1/.local/share/NuGet/v3-cache
info : global-packages: /home/user1/.nuget/packages/
info : temp: /tmp/NuGetScratch
info : plugins-cache: /home/user1/.local/share/NuGet/plugins-cache

Typical output (Linux; "user1" is the current username):

info : http-cache: /home/user1/.local/share/NuGet/v3-cache
info : global-packages: /home/user1/.nuget/packages/
info : temp: /tmp/NuGetScratchuser1
info : plugins-cache: /home/user1/.local/share/NuGet/plugins-cache

To display the location of a single folder, use http-cache, global-packages, temp, or plugins-cache instead of all.

Clearing local folders

Command-line

If you encounter package installation problems or otherwise want to ensure that you're installing packages from a remote gallery, use the locals --clear option (dotnet.exe) or locals -clear (nuget.exe), specifying the folder to clear, or all to clear all folders:

# Clear the 3.x+ cache (use either command)
dotnet nuget locals http-cache --clear
nuget locals http-cache -clear

# Clear the 2.x cache (NuGet CLI 3.5 and earlier only)
nuget locals packages-cache -clear

# Clear the global packages folder (use either command)
dotnet nuget locals global-packages --clear
nuget locals global-packages -clear

# Clear the temporary cache (use either command)
dotnet nuget locals temp --clear
nuget locals temp -clear

# Clear the plugins cache (use either command)
dotnet nuget locals plugins-cache --clear
nuget locals plugins-cache -clear

# Clear all caches (use either command)
dotnet nuget locals all --clear
nuget locals all -clear

Any packages used by projects that are currently open in Visual Studio are not cleared from the global-packages folder.

Visual Studio

Visual Studio supports clearing all local folders in the "NuGet Package Manager" options found under the Tools > NuGet Package Manager > Package Manager Settings menu command.

On the General page, select Clear NuGet local resources. Once started, this action cannot be cancelled. A progress bar will be shown and will contain the final status of the command.

The Output Window when selecting Show output from "Package Manager" will show additional details about the clear command, including any error messages.

Clear NuGet Local Resources

Managing the cache isn't presently available through the Package Manager Console.

For more information, see NuGet Options in Visual Studio.

Troubleshooting errors

The following errors can occur when using nuget locals or dotnet nuget locals:

• Error: The process cannot access the file <package> because it is being used by another process or Clearing local resources failed: Unable to delete one or more files

  One or more files in the folder are in use by another process; for example, a Visual Studio project is open that refers to packages in the global-packages folder. Close those processes and try again.

• Error: Access to the path <path> is denied or The directory is not empty

  You don't have permission to delete files in the cache. Change the folder permissions, if possible, and try again. Otherwise, contact your system administrator.

• Error: The specified path, file name, or both are too long. The fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters.

  Shorten the folder names and try again.