From the beginning NuGet used a per-solution folder
packages to store all packages for
the projects in a solution. (Does anyone else remember the numerous discussion whether
that folder belongs into the VCS or not?).
That changed with NuGet 3 and
Global Packages Folder
With Project.JSON managed projects, there is now a packages folder that is shared for all projects that you work with. Packages are downloaded and stored in the
%userprofile%\.nuget\packagesfolder. This means that if you are working on multiple UWP projects on your workstation, you only have one copy of the EntityFramework package and its dependencies on your machine. All .NET projects will acquire package references from this global shared folder. This also means that when you need to configure a new project, your project will not take time starting so that it can download a fresh copy of
EntityFramework.nupkgInstead, it will simply and quickly reference the files you have already downloaded. ASP.NET 5 uses the
%userprofile%\.dnx\packagesfolder and as that framework nears completion it will use the
%userprofile%\.nuget\packagesfolder as well.
Well, I didn't pay much attention to that change, until I ran out of disk space last week and used WinDirTree to find the culprit. Indeed, the size of my packages folder was more than 6 GB.
Therefore I wrote a small PowerShell script which deletes all packages which haven't been accessed for a configurable number of days (150 by default):Liquid error: One or more errors occurred.
Don't worry that you could delete a package which you would need later again. NuGet will just download the missing package again.
The script support the
-WhatIf parameter, so calling
.\Clear-NuGetCache.ps1 -CutOffDays 90 -WhatIf
wouldn't delete a single byte but log which folders the script would remove.