Manage Cache
Would it make sense to manage/configure the Cache on a Device with a Manifest. In this case I can set the Path to a different folder, I can manage the source path, if I have the possible option to add my own Repository also delete/clear cache at a selected time or also set a maximum size to not fulfil the Hard-drive, also let me mark application to be persistent in the cache for Active-Setup applications.
Thank you
@slaet I have trouble understanding what point you're trying to make. There's a local cache[1] of each configured source in winget (winget source list) but that only contains metadata and references to available manifests which currently is a few 100 KB in size. Can you elaborate why you think your hard drive would fill up by using winget?
Are you asking to be able to override the path where setups will be installed to, e.g. a different hard drive like D:\programs?
[1]: C:\Program Files\WindowsApps\Microsoft.Winget.Source_2020.527.608.245_neutral__8wekyb3d8bbwe\Public\index.db
@megamorf Do you work at Microsoft?
I believe @slaet is referring to the downloaded packages that sit on disk, presumably forever.
yes, thank you @riverar you pointed. I think the setup.exe from a Application will be downloaded first to the Device (to a cache folder) and start the Setup with parameters from the manifest from there? If yes, I like to manage this local cache...
The installers are downloaded to %LocalAppData%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\TempState\WinGet\ and removed by winget upon installation:
2020-5-27 10:57:36.928 [CLI ] WinGet invoked with arguments: 'install' 'glimpse.glimpse'
2020-5-27 10:57:36.928 [CLI ] Found subcommand: install
2020-5-27 10:57:36.928 [CLI ] Leaf command to execute: root:install
2020-5-27 10:57:37.170 [CLI ] Executing command: install
2020-5-27 10:57:37.204 [REPO] Default source requested, using first source: winget
2020-5-27 10:57:37.208 [REPO] Named source requested, found: winget
2020-5-27 10:57:37.208 [REPO] Source past auto update time [5 mins]; it has been at least 76 mins
2020-5-27 10:57:37.408 [CORE] Examining extension: PFN = Microsoft.Winget.Source_8wekyb3d8bbwe, ID = IndexDB
2020-5-27 10:57:37.409 [CORE] Found matching extension.
2020-5-27 10:57:39.203 [REPO] Remote source data was not newer than existing, no update needed
2020-5-27 10:57:39.288 [CORE] Examining extension: PFN = Microsoft.Winget.Source_8wekyb3d8bbwe, ID = IndexDB
2020-5-27 10:57:39.288 [CORE] Found matching extension.
2020-5-27 10:57:39.425 [REPO] Opening SQLite Index for ImmutableRead at 'C:\Program Files\WindowsApps\Microsoft.Winget.Source_2020.527.608.245_neutral__8wekyb3d8bbwe\Public\index.db'
2020-5-27 10:57:39.428 [SQL ] Opening SQLite connection: 'file:/C:/Program Files/WindowsApps/Microsoft.Winget.Source_2020.527.608.245_neutral__8wekyb3d8bbwe/Public/index.db?immutable=1' [1, 40]
2020-5-27 10:57:39.437 [REPO] Opened SQLite Index with version [1.0], last write [2020-5-27 07:08:53.000]
2020-5-27 10:57:39.571 [REPO] Performing search: Query:'glimpse.glimpse'[Substring]
2020-5-27 10:57:39.589 [CLI ] Found one app. App id: Glimpse.Glimpse App name: Glimpse
2020-5-27 10:57:39.600 [REPO] Downloading manifest
2020-5-27 10:57:39.600 [CORE] Downloading from url: https://winget.azureedge.net/cache/manifests/Glimpse/Glimpse/2ac4-0.1.2.yaml
2020-5-27 10:57:40.389 [CORE] Download completed.
2020-5-27 10:57:40.397 [CLI ] Manifest fields: Name [Glimpse], Version [0.1.2]
2020-5-27 10:57:40.399 [CLI ] Starting installer selection.
2020-5-27 10:57:40.399 [CLI ] Completed installer selection.
2020-5-27 10:57:40.700 [CLI ] Generated temp download path: "C:\\Users\\megamorf\\AppData\\Local\\Packages\\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\\TempState\\WinGet\\Glimpse.Glimpse.0.1.2"
2020-5-27 10:57:40.706 [CORE] Downloading to path: "C:\\Users\\megamorf\\AppData\\Local\\Packages\\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\\TempState\\WinGet\\Glimpse.Glimpse.0.1.2"
2020-5-27 10:57:40.725 [CORE] Started applying motw to "C:\\Users\\megamorf\\AppData\\Local\\Packages\\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\\TempState\\WinGet\\Glimpse.Glimpse.0.1.2"
2020-5-27 10:57:40.729 [CORE] Finished applying motw
2020-5-27 10:57:40.733 [CORE] Downloading from url: https://github.com/glimpse-editor/Glimpse/releases/download/v0.1.2/glimpse-0.1.2.msi
2020-5-27 10:59:08.100 [CORE] Download hash: 99c3df2884310cb74c39a15fb63e93fbf2112f581dc5325b37123467618d89e8
2020-5-27 10:59:08.101 [CORE] Download completed.
2020-5-27 10:59:08.111 [CLI ] Installer hash verified
2020-5-27 10:59:08.115 [CLI ] Installer args: /passive /log "C:\Users\megamorf\AppData\Local\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\TempState\WinGet\Glimpse.Glimpse.0.1.2.log"
2020-5-27 10:59:08.122 [CLI ] Successfully renamed downloaded installer. Path: "C:\\Users\\megamorf\\AppData\\Local\\Packages\\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\\TempState\\WinGet\\Glimpse.Glimpse.0.1.2.msi"
2020-5-27 10:59:08.127 [CLI ] Starting installer. Path: "C:\\Users\\megamorf\\AppData\\Local\\Packages\\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\\TempState\\WinGet\\Glimpse.Glimpse.0.1.2.msi"
+ 2020-5-27 10:59:36.467 [CLI ] Removing installer: "C:\\Users\\megamorf\\AppData\\Local\\Packages\\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\\TempState\\WinGet\\Glimpse.Glimpse.0.1.2.msi"
2020-5-27 10:59:36.547 [CLI ] Leaf command succeeded: root:install
Note that many setups are stored in %windir%\Installer so that they can be uninstalled later which has nothing to do with winget.
@riverar No, I'm just an enthusiast who wants this project to succeed.
@megamorf The files still remain in app installer's INetCache. Look in %localappdata%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\AC\INetCache.
@riverar That path is empty for me after installing the package with ID glimse.glimpse which is an msi based installer.
@megamorf The folders/files are hidden. Try again.


@riverar You're right. I can confirm that. I typically have show all hidden and system files enabled but not on this computer, sorry about that.
PS C:\Users\megamorf> gci -Recurse -Force $env:LocalAppData\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\AC\INetCache | select fullname
FullName
--------
C:\Users\megamorf\AppData\Local\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\AC\INetCache\6DZJX28P
C:\Users\megamorf\AppData\Local\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\AC\INetCache\NB11U0ZX
C:\Users\megamorf\AppData\Local\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\AC\INetCache\container.dat
C:\Users\megamorf\AppData\Local\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\AC\INetCache\6DZJX28P\2ac4-0.1.2[1].yaml
C:\Users\megamorf\AppData\Local\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\AC\INetCache\NB11U0ZX\glimpse-0.1.2[1].msi
exactly, this Folder %localappdata%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\AC\INetCache I like to manage. In my Case this folder is Empty after installing some Packages, but maybe I need the app for another user to run the User Conditions again, for that I like to have more options to manage the content, like hold an application in that cache as persistent for later use. For sure the uninstall is most based in the MSI-ID to run without the sources, and for some exe there is a uninstall.exe at the Installation Path, but what about exe's that only run setup.exe again for uninstall? And the %localappdata% is also based on a User-Profile, that's why I like to manage it, on a different location, for example c:\windows\wingetcache that the folder is accessible to all Users on a Device. Would that make sense?
Further to this, cache management would be nice from the perspective of resuming installs. For example if you call winget install on an application, it gets to 100% download but for whatever reason (maybe a user mistake) the uac prompt its not passed then the installation is cancelled. If you run winget install again...it downloads it again. It would be preferrable to use whats already downloaded.
Correct me if I wrong about this.
@denelon
any updates on this feature? I think keeping itself clean is super important to an OS system.
I've been using choco for a long time and waiting to switch to this (official i guess?) package manager.
Windows (LTSC) rocks~
@enihcam,
WinGet downloads the installer for use, and if the install succeeds, the installer is removed. It's left in the cache when there is a failure to be able to avoid a download for a second attempt. I'm not sure if that is sufficient to close this issue, or if there are other specific concerns required to close this issue.
@denelon That wasn't the case earlier, but maybe it got fixed? @slaet are you still seeing this behavior?
@riverar, thanks for the response. I think this ask includes adding some additional metadata to the manifest for modifying default cache behavior. I don't think that's the approach we would take.
We've been discussing a "download" command so files could be saved for offline use. Of course, there are plenty of edge cases regarding whether the installer WinGet detected as the "best match" for the current environment as opposed to some set of installers by locale, architecture, scope, etc. We also have been looking at the best mechanism for including the license.xml file for Microsoft Store packages.
Maybe we could consider a(n) command/argument to "empty" the local cache manually, and/or settings to drive the behavior.
@denelon Oh ok. I understood the issue to be that anything winget downloaded was not getting cleaned up. If it's now getting cleaned up (even if periodically) then I'd agree there's nothing to do here.
Maybe we could consider a(n) command/argument to "empty" the local cache manually, and/or settings to drive the behavior.
Thanks for quick reply. yes, empty command will definitely work. Or, is it possible to get Windows built-in Disk Cleanup tool to take over the chore responsibility? e.g. add an item Winget Temporary Files in Files to delete.

Not sure if this is exactly what this request is for, but I would like to control a cache location. We use Ninite which has a cachepath option: https://ninite.com/help/features/cache.html
We use one script to only update the specified installers (with a switch called /cleancache) in that cachepath (no install done) which also removes old installers. Then each machine calls an update pointing to the cachepath. If that is what is being described here, I would love it.
We've changed the location for the installers to land in the %TEMP% path. @enihcam The Cleanup UI does cover the directory.
As cache management shouldn't be handled in a manifest which would impact "all" users, we think cache management should be a separate Issue. I've created a discussion to have further conversation.
@slaet this issue has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for 7 days. It will be closed if no further activity occurs within 7 days of this comment.
@slaet this issue has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for 7 days. It will be closed if no further activity occurs within 7 days of this comment.
No you don't.
Any updates on this?
I solve the Installer failed with exit code: 2 using this: winget install -i --id <name.package>
-i,--interactive / Request interactive installation; user input may be needed
before I unistalled the program using winget uninstall
but I dont know if this solution work for every cases possible
can also try an setup.exe manual from the app site (before try to reinstall) :|
We've added the WinGet Download command to enable downloading applications.