Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clean up any temp nuget folder actions after NuGet operations #622

Closed
ferventcoder opened this issue Feb 10, 2016 · 5 comments
Closed

Clean up any temp nuget folder actions after NuGet operations #622

ferventcoder opened this issue Feb 10, 2016 · 5 comments
Assignees
Milestone

Comments

@ferventcoder
Copy link
Member

ferventcoder commented Feb 10, 2016

  • %TEMP%\NuGetScratch folder
  • %TEMP%\x\nuget folder
  • %TEMP%\nuget\packagename - don't remove this
@ferventcoder ferventcoder self-assigned this Feb 10, 2016
@ferventcoder ferventcoder added this to the 0.9.10 milestone Feb 10, 2016
@ferventcoder ferventcoder changed the title Clean up %TEMP%\NuGetScratch folder after NuGet operations Clean up any temp nuget folder actions after NuGet operations Feb 10, 2016
@ferventcoder
Copy link
Member Author

@mrdima This is now fixed.

@ferventcoder
Copy link
Member Author

ferventcoder commented May 27, 2016

We already handle the nuget\packagename folder with #479

@ferventcoder
Copy link
Member Author

This should help reduce the size when embedding files in the package.

ferventcoder added a commit that referenced this issue May 28, 2016
Certain operations you want to be performed without logging warnings.
Ensure that those operations can be performed without logging at a
level that may alarm the user. Log only to the file instead.
ferventcoder added a commit that referenced this issue May 28, 2016
`TEMP\NuGetScratch` and sometimes a `TEMP\x\Nuget` folder are created
by NuGet Core, however it doesn't clean up after itself on this. It is
expected for you to call `OptimizedZipPackage.PurgeCache()`, but this
does not appear to actually remove the folder because PurgeCache is
dependent on the GUID that it creates for the subdirectory. It doesn't
hold a reference to that and so it comes up with one that doesn't exist
by the time we call it.

Handle cleaning up those caches at the end of most runs.
ferventcoder added a commit that referenced this issue May 28, 2016
* stable:
  (doc) update CHANGELOG/nuspec
  (GH-753) Get-WebFileName Matches on Invalid Chars
  (doc) update CHANGELOG/nuspec
  (GH-356) Resolve sources by name
  (GH-732) Request/Response Timeout configurable
  (maint) formatting
  (GH-751) Use package name/version from env vars
  (GH-752) Combine Push timeout and execution timeout
  (GH-622) Remove NuGet temp folders
  (GH-622) Allow silent retries
  (GH-584) License loading occurs in DLL
  (GH-584) update licensing docs
  (doc) update CHANGELOG/nuspec
  (GH-733) Don't pass some args to dependencies
  (doc) update CHANGELOG/nuspec
@dietmarb01
Copy link

The NuGetScratch folder is NOT deleted in the following situation:

  • Choco packages are deployed through a Windows service (headless operation), running as SYSTEM.
  • Choco's cacheLocation has been set to C:\tmp.

Choco creates and uses C:\tmp\NuGetScratch for the installation itself, but leaves it behind after completion.
Monitoring with procmon.exe shows a single attempt to access C:\Windows\Temp\NuGetScratch which fails, as there is no such folder.

@ferventcoder
Copy link
Member Author

@dietmarb01 sounds like a possible bug. Would you mind filing a new issue so we can take care of it ? Thanks in advance!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants