It seems that NuGet puts some temporary files there with extracted packages and never cleans up. It's worth noting that this isn't a year's worth of cache or anything - all the timestamps are from a 3-day period.
I believe that NuGet should clean these files/folders up because they are apparently each used only once and never again.
Seconding the above - we run out of disk space on the OS drive every couple of weeks if this isn't purged regularly. Would be nice to either have a fix or open-source the code to accept a patch.
Please reopen, the issue is not solved by the suggested fix (using VS2015).
Most likely the problem is long-running VS sessions, which accumulate lots of data across several days. The once-in-a-while clearance is a bogus fix, unused files should not wait until all the nuget/VS instances quit — that effectively constitutes a HD space leak.
Use cases:
Previous versions of Windows and Visual Studio were much more leaky and buggy, and developers were forced to restart often enough. Unfortunately, modern Windows and modern VS are stable enough not to require that practice.
If forced restart is the solution to this resource leak that nuget suggests, please talk to engineers from Windows and/or Visual Studio teams to plant some bugs/leaks in their products to make it happen. Unless the crash frequency of Visual Studio increases nuget needs to implement a proper fix here.
C:\Users\ *** \.nuget>nuget.EXE
NuGet Version: 3.4.4.1321
Microsoft Visual Studio Professional 2015
Version 14.0.25424.00 Update 3
Chiming in to say I have the same issue. Just had to purge 18 GB. I leave VS open on the same solution as long as possible (until it crashes), sometimes for weeks on end. Often I have two instances open for different solutions as well.
Microsoft Visual Studio Professional 2015
Version 14.0.25431.01 Update 3
NuGet Version: 3.4.4.1321
Same issue here. Deleted 18GB of NuGetScratch files. I'm using a single VS solution with ~80 NuGet packages (updated only once a year or so).
Microsoft Visual Studio Professional 2015
Version 14.0.25431.01 Update 3
NuGet Version: 3.4.4.1321
18 GB ? ... how about 124 GB ...
So it is safe to just empty out this AppData\Local\Temp\NuGetScratch
folder?
This is still a problem, I am creating a new issue.
I have experienced same problem. Cache folder is too big. 64 GB.
Gigabytes, Karl.
Is there a solution to this. We are using the latest VS 2017 and still have this issue. I have had to setup a clean process that deletes files/folders older than 3 days.
I would rather move the location to a different drive.
How can we move the location?
So it is safe to just empty out this
AppData\Local\Temp\NuGetScratch
folder?
I cleared it with no issues.
Also I created ClearNuGetCache.bat
in folder C:\Users\<username>\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup
with this conent:
echo OFF
set folder="C:\Users\<username>\AppData\Local\Temp\NuGetScratch"
IF EXIST %folder% (
echo ON
cd /d %folder%
for /F "delims=" %%i in ('dir /b') do (rmdir "%%i" /s/q || del "%%i" /s/q)
) ELSE (
echo ON
echo Folder for cleanup was not found.
)
Most helpful comment
Please reopen, the issue is not solved by the suggested fix (using VS2015).
Most likely the problem is long-running VS sessions, which accumulate lots of data across several days. The once-in-a-while clearance is a bogus fix, unused files should not wait until all the nuget/VS instances quit — that effectively constitutes a HD space leak.
Use cases:
Previous versions of Windows and Visual Studio were much more leaky and buggy, and developers were forced to restart often enough. Unfortunately, modern Windows and modern VS are stable enough not to require that practice.
If forced restart is the solution to this resource leak that nuget suggests, please talk to engineers from Windows and/or Visual Studio teams to plant some bugs/leaks in their products to make it happen. Unless the crash frequency of Visual Studio increases nuget needs to implement a proper fix here.