Global Packages and Cache Folders

This section documents MSBuild 18.9, the .NET SDK 10.0.402 (with its dotnet CLI) and NuGet 7.9, as published in the MSBuild, .NET and NuGet documentation on learn.microsoft.com, which is the reference these pages are written and verified against. Material about .NET 11 / NuGet 8.0 is still in preview and is always flagged as such — never presented as baseline.

This content was generated with the assistance of AI and should be verified against the official documentation before being relied on in production.

The C# Reference bibliography lists the reference material consulted while preparing these pages.

NuGet keeps four folders per user: the global-packages folder where restored packages live, the HTTP cache of downloaded feed responses, a temp folder and a plugins cache. Knowing where they are — and which one to clear — solves most "stale package" problems and is the basis of CI caching. This page uses NuGet 7.9.0 (.NET SDK 10.0.402) on Linux.

The folders

dotnet nuget locals all --list on a fresh profile:

http-cache: ~/.local/share/NuGet/http-cache
global-packages: ~/.nuget/packages/
temp: /tmp/NuGetScratchroot
plugins-cache: ~/.local/share/NuGet/plugin-cache
Folder Contents Override

global-packages

Every restored package, extracted: <id>/<version>/ (How Package Installation Works)

NUGET_PACKAGES; globalPackagesFolder in nuget.config; RestorePackagesPath (MSBuild only)

http-cache

Raw feed responses and .nupkg downloads; an entry is fresh for 30 minutes

NUGET_HTTP_CACHE_PATH

temp

Scratch files during restore and install

NUGET_SCRATCH

plugins-cache

Results of credential-provider and other plugin discovery

NUGET_PLUGINS_CACHE_PATH

 
NUGET_PACKAGES=/srv/nuget/packages NUGET_HTTP_CACHE_PATH=/srv/nuget/http \
NUGET_SCRATCH=/srv/nuget/tmp NUGET_PLUGINS_CACHE_PATH=/srv/nuget/plugins \
  dotnet nuget locals all --list
http-cache: /srv/nuget/http
global-packages: /srv/nuget/packages
temp: /srv/nuget/tmp
plugins-cache: /srv/nuget/plugins

CI systems cache the global-packages folder (keyed on lock files) by pointing NUGET_PACKAGES at a path inside the workspace (CI Builds and Caching).

Source: Managing the global packages and cache folders: global-packages, http-cache, temp, plugins-cache, Viewing folder locations.

Clearing

dotnet nuget locals http-cache --clear
dotnet nuget locals global-packages --clear
Clearing NuGet HTTP cache: ~/inst-http
Local resources cleared.
Clearing NuGet global packages folder: ~/inst-gp
Local resources cleared.

(here with the two folders redirected to a scratch location; the global-packages folder was removed entirely). Which one to clear:

  • A package was re-uploaded under the same version on a private feed — the global-packages folder (restores never re-download an existing version) and the HTTP cache.

  • A just-published version is not found — the HTTP cache, or --no-http-cache for one restore: the feed’s version list may be cached for up to 30 minutes.

  • Everything — dotnet nuget locals all --clear; the next restore downloads every package again.

Clearing fails with "being used by another process" when an IDE or build server holds files (close them, run dotnet build-server shutdown), and with "Access to the path is denied" when the folders were created by another user — the result of mixing sudo and normal builds (Environment Variables, Completion and Telemetry).

Source: Clearing local folders, Troubleshooting errors, dotnet nuget locals: Troubleshooting.

Cleaning old packages

The global-packages folder only grows. NuGet offers half of a cleanup: the updatePackageLastAccessTime setting makes every restore touch the .nupkg.metadata of each package it uses, so their timestamps show what is still in use:

<config>
  <add key="updatePackageLastAccessTime" value="true" />
</config>

NuGet has no command to delete the unused ones; community tools do it. A cleanup must delete a package’s .nupkg.metadata first — restore treats a folder with that file as a complete package. Restores of projects that are already up to date do not touch the timestamps, so wait some days after enabling the setting.

Source: Cleaning the global packages directory.

Fallback folders

fallbackPackageFolders in nuget.config (or the RestoreFallbackFolders property) lists read-only folders in the global-packages layout that restore checks before downloading — once used for the offline package cache that early .NET Core SDKs shipped. A package found there is used in place, not copied. They are rarely needed today; an offline or air-gapped build is better served by a local feed (Package Sources and Source Mapping).

Source: nuget.config: fallbackPackageFolders.

Common mistakes

  • Clearing everything for every problem — slow, and usually only the HTTP cache matters.

  • Deleting files inside a package folder — delete the whole <id>/<version> folder, .nupkg.metadata first.

  • Mixing root and user builds — folders the user cannot clear.

References