winget-cli
winget-cli copied to clipboard
microsoft
First usage feedback: multiple non-silent fails, one crash, and two types of repeats
Brief description of your issue
Sorry if this shouldn't be reported this way, but I'm not yet up-to-speed on the Microsoft ways-of-work on Github.
After installing winget-cli this morning, and running winget upgrade --all, I got the following feedback:
- Multiple non-silent fails
- One crash of winget
- Looping installation after fail
- Upgrades of up-to-date applications
Steps to reproduce
Have an old 32-bit version of Teamviewer installed on your 64 machine, together with any old version of the other apps listed below under Actual behaviour.
Then run winget upgrade --all as administrator in a Windows Terminal session running Powershell as default.
Expected behavior
Winget to update these packages, and kill a running download when pressing CTRL+C.
Actual behavior
While downloading the Unity update of 2GB, I pressed CTRL+C because I needed my bandwidth for a Teams meeting, but it seems the download kept running even though I got my Powershell prompt back.
Multiple packages (also a number of packages not listed here) have visible installers. It wouldn't be too much of an issue if these would be running in the background, but they are being pushed as top window, and get the focus of Windows, which makes it possible to accidentally cancel an installation, otherwise interrupt an installation, or close an error message.
- Battle.Net: Keeps re-installing the update (and launching after installation).
- Discord: Installer fails to install, because Discord.exe was still running. 2nd attempts installs a version that still needs to update when running for the first time.
- LockHunter: Keeps re-installing the update (and popping up their website after installation).
- Parsec: Installer hash does not match; this cannot be overridden when running as admin.
- PyCharm Community Edition: Installation fails, because it attempts to install into a non-empty directory. Then it re-tries, gives the same error, and continues to the next package. As long as the error is open, winget does not continue.
- Speccy: Keeps re-installing the update.
- Spotify: Fails because it can only be installed under user level, and not as administrator.
- TrackMania Nations Forever: Keeps re-installing the update (500MB slow download with visible installer).
- TeamViewer: Returns error 0x80072f7c and exits winget. After manually updating, it successfully skips this package.
- CORSAIR iCUE 4 Software: Installer freezes after spawning multiple C++ Application Development Frameworks (QtWebEngineProcess.exe). winget reported error 1603 and continued after I killed the installer.
- euroscope: Installer failed with exit code: 1603 (no user-interaction happened)
- PowerShell: Installation killed my PowerShell session, and with that it killed winget
- Unity: Keeps re-installing the update (2GB download!)
- Unity Hub: Keeps re-installing the update
- Ubisoft Connect: Keeps re-installing the update
- Visual Studio Community 2019: Keeps re-installing the update
- Barrier: Installer fails because the process takes too long to be killed
- Epic Games Launcher: Installer failed with exit code: 1603 (no user-interaction happened)
- Visual Studio Code: Keeps re-installing the update, application launches after installation
Mozilla Firefox, VLC media player, Zoom and Adobe Acrobat Reader DC aren't automatically updating at all with winget upgrade --all and return No applicable update found. when trying to upgrade them one-by-one.
Environment
Windows Package Manager v1.0.11451
Copyright (c) Microsoft Corporation. All rights reserved.
Windows: Windows.Desktop v10.0.19041.1023
Package: Microsoft.DesktopAppInstaller v1.11.11451.0
PS C:\Users\maste> winget upgrade
Name Id Version Available Source
----------------------------------------------------------------------------------------------------------------
Battle.Net Blizzard.BattleNet Unknown 1.22.0.12040 winget
Discord Discord.Discord 1.0.9000 1.0.9002 winget
LockHunter CrystalRich.LockHunter Unknown 3.3.4.139 winget
Mozilla Firefox Mozilla.Firefox 84.0.2 88.0.1 winget
Parsec ParsecCloudInc.Parsec 150-36 150.47 winget
PyCharm Community Edition JetBrains.PyCharm.Community 203.6682.179 2021.1.1 winget
PyCharm Community Edition JetBrains.PyCharm.Community 211.7142.13 2021.1.1 winget
Speccy Piriform.Speccy 1.32 1.32.774 winget
Spotify Spotify.Spotify 1.1.60.668.gff09d345 latest winget
TrackMania Nations Forever Nadeo.TrackManiaNationsForever Unknown 2.11.26 winget
Unity UnityTechnologies.Unity 2018.4.26f1 2021.1.7f1 winget
Unity Hub UnityTechnologies.UnityHub 2.2.2 2.4.3 winget
Ubisoft Connect Ubisoft.Connect 38.2 121.0.0.10451 winget
VLC media player VideoLAN.VLC 3.0.11 3.0.14 winget
Zoom Zoom.Zoom 5.3.1 (52879.0927) 5.6.961 winget
Visual Studio Community 2019 Microsoft.VisualStudio.2019.Community 16.8.31005.135 16.10.31321.278 winget
Barrier DebaucheeOpenSourceGroup.Barrier 2.3.3-release 2.3.3 winget
CORSAIR iCUE 4 Software Corsair.iCUE 4.9.338 4.11.274 winget
euroscope gergelycsernak.euroscope 3.2 3.2.1.0 winget
Adobe Acrobat Reader DC Adobe.AdobeAcrobatReaderDC 21.001.20155 2021.001.20155 winget
Epic Games Launcher EpicGames.EpicGamesLauncher 1.1.257.0 1.2.17.0 winget
Visual Studio Code Microsoft.VisualStudioCode 1.56.2 1.56.2.054a929533 winget
Logs: DiagOutputDir.zip
Edit: I'm hijacking this initial response to put the list of related features so it's easier to see progress. I'll continue to make edits in this top response as we continue discussing topics on this thread. In general, we have been looking to close these "large collection of issues" Issues, but as this one was early and so helpful, I'm going to keep it open and honor the original intent.
- #372
- #418
- #607
- #910
- #1748
@Master-Guy this is awesome feedback! Thank you for taking the time to be so thorough here.
There are several different things you are reporting. I think we have Issues for many of them. Be sure to add your 👍 to those issues to help us prioritize.
There may be a couple of new asks. I don't think anyone has created a new feature to request the ability to specify either a preference or a requirement for a setting in winget settings to "prefer" or "require" silent install vs. silent with progress (our default).
Edit: It's this one:
- #910
The "list" command/feature is used to do most of the heavy lifting to match manifests in the source to Apps in Add / Remove Programs. In some cases, an adjustment to a manifest will address failure to update. In other cases, we have features to add additional keys to the manifest to help with better matching.
The "main" actionable item we can look at in the client in this issue is "kill a running download when pressing CTRL+C."
Thank you! I'm really looking forward to using this on an enterprise level, but it requires some finetuning :)
@Master-Guy
We've made improvements for [Ctrl]+[C] in several areas. Can you confirm if the "kill a running download when pressing CTRL+C" is resolved?
I believe we've isolated most of the other issues you've reported. The work is ongoing and primarily tracked with #1243.
@denelon thank you for getting back to me. I can confirm that CTRL+C now kills the download.
Since I've re-installed my Windows, a lot of the checks are uncheckable for me now. Other things that I'm noticing now:
Ryzen fails due to failed version comparison:
Discord fails due to it still running:
13008> 2021-10-02 08:32:32> Program: Starting Squirrel Updater: --install . /s 13008> 2021-10-02 08:32:32> Program: Starting install, writing to C:\Users\maste\AppData\Local\SquirrelTemp 13008> 2021-10-02 08:32:32> Program: About to install to: C:\Users\maste\AppData\Local\Discord 13008> 2021-10-02 08:32:32> Program: Install path C:\Users\maste\AppData\Local\Discord already exists, burning it to the ground 13008> 2021-10-02 08:32:32> IEnableLogger: Failed to remove existing directory on full install, is the app still running???: System.IO.IOException: Access to the path 'C:\Users\maste\AppData\Local\Discord' is denied.
Unity is still being installed as a separate version when doing upgrade --all. Suggestion: Remove the upgrade option from Winget for this application.
@Master-Guy
We've been busy making tons of improvements and we're close to getting Windows Package Manager 1.3 flighted for "Windows Insider Release Preview". That's the last step before GA.
Are there any problems you're having that haven't been reported yet? I think we're close to being able to close this issue 😊
I did re-install Windows 11 in the meantime, so this might not be completely representative anymore :)
Running winget upgrade --all now, will post the results when finished.
Thanks for all your very hard work on this project!
Visual Studio
Visual Studio Community is updating very nicely! Both 2019 and 2022 updated sequentially and without issues.
However Visual Studio Build Tools don't seem to be updated automatically.
Discord
The Discord installer fails, because Discord still is in use. Even though the installation fails, it reports a success in the prompt.
SquirrelSetup.log
No indication of installations running
Multiple apps are installing in the background, invisible, even though no arguments were given to do so.
Updating Docker (for example) takes a while, and with winget showing `Starting package install...` instead of `Installing package`, it makes it appear as if it has issues starting the setup, even though it's actually installing in the background.
EPIC Games
EPIC games fails to install because it's still running, but this one gives a correct error message.
WinGet-EpicGames.EpicGamesLauncher.1.3.23.0-2022-06-22-17-15-14.256.log
Run complete
After the first run, except for the expected Discord and EPIC Games, there are a number of other applications also still showing up in the list.
Running the command again, it does go through most of the installers, and most of those show the appropriate dialogs. None of them, however, upgrade to the version shown as available.
The weird part though, is that it doesn't even create a log file for the installation of two of the packages:
- Google Chrome
- Ubisoft Connect
Corsair iCue
The installation of Corsair iCue seems to go without issues, but winget doesn't tell me I need to reboot the system in order to complete the installation. This caused me to not have any audio after the installation. It also doesn't launch the application. After manually launching the application, it showed me the reboot message.
WinGet-Corsair.iCUE.4.4.24.193-2022-06-22-17-06-50.711.log
Discord is a tricky one. As a squirrel installer, the initial child process spawned to run the installer returns with "0" success. Then the child process continues to run. If it fails, we don't get the response. We're going to likely need to watch the entire process tree.
- #372
- #418
- #1748
Corsair iCue "might" be willing to give a custom return code so we can inform the user a reboot is required with expected return codes: https://github.com/microsoft/winget-cli/blob/9056c0fc3fe4a362ef2644ba080f88698836576b/schemas/JSON/manifests/v1.2.0/manifest.installer.1.2.0.json#L172-L201
Otherwise, we would need add "post install display notes" to the manifest:
- #607
No indication of installations running
What kinds of ideas do you have that might improve this? Windows Package Manager essentially executes the installer and doesn't show progress until we get indication from the installer.
Maybe as a more "appealing" placebo, we could have a timeout on the initial message and then switch the message to "Installing package..."
or
"Installing <packageName> <packageVersion> [<packageIdentifier>]...".
Epic Games
Error 1603 is returned, but it's a bit unclear to the user. We've been discussing improving the output to the user so they have some idea of what might be happening. The challenge with MSI Error 1603 is it isn't really clear what happened.
Visual Studio
I'm not sure what's happening with Build Tools, I'll have to ask around or dig in deeper.
Run complete
I'm not sure why logs aren't produced for:
- Google Chrome
- Ubisoft Connect
Appending a message Installing <packageName> <packageVersion> [<packageIdentifier>]... after confirming the executable launched sounds like a good thing to do.
For Epic: Can we ask them to return the correct returncode if it detects the app running?
VS Build Tools: My guess is there just isn't a winget package available for that one.
Appending a message
Installing <packageName> <packageVersion> [<packageIdentifier>]...after confirming the executable launched sounds like a good thing to do.
👍
For Epic: Can we ask them to return the correct returncode if it detects the app running?
I'm not sure there is a better return code for MSI installers. There may be an opportunity to return a custom error code. It might also be a good time to consider migrating from MSI to MSIX (assuming there aren't any blockers). At they end of the day, they should be in control of their customer experience.
VS Build Tools: My guess is there just isn't a winget package available for that one. 🤔
@Master-Guy we just released WinGet 1.4 today. I'm going through some of the older issues to see if they are resolved and what is still outstanding. Would you mind giving an update?
Hi @denelon,
Thank you for coming back to me on this.
Running version 1.4.3132-preview at this moment, I'm encountering an issue when trying to update my packages.
The command winget update --accept-package-agreements --all gives me the error message telling me that the arguments provided can only be used with a query. Looking at the description of these arguments in winget update -? that confuses me a lot. Not only doesn't it tell me which argument it's showing the error on, but the -? messages give the impression that it was made just for this purpose.
--accept-package-agreements Accept all license agreements for packages
-r,--recurse,--all Upgrade all installed packages to latest if available
The same goes for running winget update --log "C:\temp\winget.log" --all, which gives the same error. I want to simply update all my packages, and store the logs in a single logfile.
Can you tell me if this is on purpose? I'm holding back on updates so that I can verify them with logs.
@Master-Guy,
No, this is a bug (or a pair of them depending on how one perceives things).
I'm able to reproduce both errors. You are correct, the intent of "winget upgrade --all --accept-package-agreements" would be to upgrade all packages and accept their agreements to avoid an interactive prompt per agreement.
I know we've been doing some refactoring for arguments that "don't make sense" or conflict with each other. I'm guessing we haven't seen this particular report due to the fact that none of the packages in the "winget" source have "Agreements" today, and the "msstore" source isn't providing version numbers in the upgrade flow for us to detect when upgrades are available (yet).
Please let me know when to retest, so I can fill you in with the results of updating my current list of applications :)
@Master-Guy,
I had a quick chat with engineering.
We're going to confirm the behavior of having both "--all" and "--accept-package-agreements" for upgrade (in an open PR).
- https://github.com/microsoft/winget-cli/pull/2862
The "--log" argument is where the "installer" places it's logs (if supported). It likely the file would get overwritten by each subsequent installer. In a world where parallel install is supported (MSIX only) it gets even messier.
We're going to need to think about trying to place "all" installer logs from commands that operate on sets of packages into one location.
@Master-Guy
We've been making lots of progress on WinGet. We announced WinGet configuration and Dev Home at Microsoft Build this year.
I just finished "hijacking" my initial reply to keep track of the related issues at the top of this Issue. @Trenly has been helping as a community moderator over at winget-pkgs and we recently got an update for the fabric bot used here to help put labels on issues and build rules so the moderators can help with triage. He suggested an update here this morning since he's been plowing through the open issues.
Another set of notable improvements to help with troubleshooting have also been added. You can now specify verbose logging in your settings, and you can use "--open-logs" or the shorter "--logs" to launch the file explorer with the log directory after the command completes. If you don't want to default to verbose logs in settings, you can use "--verbose-logs" as an argument.
The Visual Studio and .NET teams have automated publishing for their packages in the WinGet community repository, and lots of other bugs have been discovered (some of them have even been squashed). I'd love to get an update on your end to see how we've made progress (or not).
I forgot to mention the PowerShell module which might also be more to your liking rather than trying to fight the CLI output. WinGet Client PowerShell module
Issues related to the PowerShell cmdlets are labeled with "PowerShell".
Hi @denelon, thank you for your reply and keeping up with this. It's good to see that this is still being followed up, and that improvements are still being made. Taking you with me on this new cycle of updates:
winget upgrade --include-unknown
Going through the help message (-?), I see that --include-unknown is missing:
Combining all the wanted items, I reached the following command:
winget upgrade --include-unknown --silent --accept-package-agreements --accept-source-agreements --recurse --recurse --open-logs --verbose-logs --disable-interactivity
Please note that I'm running this command in a regular, non-elevated command prompt (WindowsTerminalPreview 1.18.1462.0) first.
Having the Starting package install... there still doesn't tell me that it is actually installing. Because of this, I'm not sure if I can safely CTRL+C the process at this moment.
Also for the screenshot above: Even though Winget tells me that there are 33 upgrades available, it only wants to process 24? This is very confusing for me as an end-user, since I don't have any information on why this is.
Information on the applications updating:
Algodoo [Algoryx.Algodoo] came with an unexpected UAC prompt
Android Studio [Google.AndroidStudio] came with an unexpected UAC prompt
Crossout Launcher [GaijinNetwork.Crossout] doesn't match the hash
Docker Desktop [Docker.DockerDesktop] came with a UAC prompt, but at least told me about it
Git [Git.Git] came with a UAC prompt, but at least told me about it
GNU Privacy Guard [GnuPG.GnuPG] came with an unexpected UAC prompt
OBS Studio [OBSProject.OBSStudio] came with an unexpected UAC prompt, and then failed to install even though it shouldn't
Oh My Posh [JanDeDobbeleer.OhMyPosh] installed successfully without prompts
Unity 2021 [Unity.Unity.2021] is installing (or attempting to install) version 22f1, even though only newer versions have been installed on my system. I'm not sure where this goes, but it does not become visible in Unity Hub
Ubisoft Connect [Ubisoft Connect] came with an unexpected UAC prompt
WinRAR [RARLab.WinRAR] came with an unexpected UAC prompt
Wireshark [WiresharkFoundation.Wireshark] came with an unexpected UAC prompt
Zoom [Zoom.Zoom] installed successfully without prompts
WinSCP [WinSCP.WinSCP] came with an unexpected UAC prompt
Python 2 [Python.Python.2] came with an unexpected UAC prompt
Microsoft .NET Windows Desktop Runtime 6.0 [Microsoft.DotNet.DesktopRuntime.6] came with an unexpected UAC prompt
Microsoft Visual C++ 2015-2022 Redistributable (x86) [Microsoft.VCRedist.2015+.x86] came with an unexpected UAC prompt
EA app [ElectronicArts.EADesktop] tells me that it will prompt for UAC, but never does. It does however show the main application screen after installation.
Microsoft Teams [Microsoft.Teams] fails to install
Microsoft Visual Studio Code [Microsoft.VisualStudioCode] installed successfully without prompts
Epic Games Launcher [EpicGames.EpicGamesLauncher] came with an unexpected UAC prompt and fails to install
GitHub CLI [GitHub.cli] came with an unexpected UAC prompt
VLC media player [VideoLAN.VLC] came with an unexpected UAC prompt and fails to install
Microsoft Visual C++ 2015-2022 Redistributable (x64) [Microsoft.VCRedist.2015+.x64] came with an unexpected UAC prompt
The full logs for this set of update installations can be found here: https://1drv.ms/u/s!AhuO4Fh8ycm8l4lSllFjTDH6XkAQaA?e=Hj6WL9
After the full set, I ran winget upgrade --include-unknown again:
Still in the list, even though it just updated according to the information I was shown:
- Algodoo [Algoryx.Algodoo]
- Android Studio [Google.AndroidStudio]
- OBS Studio [OBSProject.OBSStudio]
- Unity 2021.1.23f1 [Unity.Unity.2021]
- Unity 2021.1.28f1 [Unity.Unity.2021]
- Python 2.7.15 (64-bit) [Python.Python.2]
- Microsoft Windows Desktop Runtime - 6.0.3 (x86) [Microsoft.DotNet.DesktopRuntime.6]
- Microsoft Windows Desktop Runtime - 3.1.22 (x64) [Microsoft.DotNet.DesktopRuntime.6]
- Microsoft Visual Studio Code [Microsoft.VisualStudioCode]
- Microsoft Windows Desktop Runtime - 5.0.13 (x64) [Microsoft.DotNet.DesktopRuntime.6]
Trying to install the unknown packages:
NVM and WinDirStat.zip
Concluding this, all the feedback for this round:
- To me, the available updates after updating are the worst as either the update didn't work even though it reported a success, or the installation passed, but it isn't the latest reported version that is installed.
- When I'm running with
--silent, I do not expect to get any UAC prompts. If an application requires Elevated Permissions, it should be skipped when not already running elevated. - With 2 and 3 duplicate ID's, I can explain why there are 3 less updates running then there are applications reporting an update available. However, this does not explain the other 6 missing updates
- The version installed according to WinGET doesn't reflect the actual state for a number of applications. For example Discord has a newer version after auto-updating, then when running the installer. This makes the 'update' actually a downgrade.
-
WinGET updateis reporting version that aren't applicable to my system that it aware of. It does report this when trying to actually update/install, but still does report the update as available
Going through the help message (-?), I see that --include-unknown is missing
Interesting. I see it in the screenshot you shared as -u,--unknown,--include-unknown, right below -r,--recurse,--all.
Also for the screenshot above: Even though Winget tells me that there are 33 upgrades available, it only wants to process 24? This is very confusing for me as an end-user, since I don't have any information on why this is.
I completely agree. I believe this issue is being experienced by many users, and is tracked in
- #2493
Having the Starting package install... there still doesn't tell me that it is actually installing. Because of this, I'm not sure if I can safely CTRL+C the process at this moment.
This is a great point, and I think @denelon noticed this a while ago in
- #2272
Still in the list, even though it just updated according to the information I was shown:
This is great information. Some of them can be explained as known issues. For example - the Desktop Runtimes are installed side by side and are also heavily impacted by issues related to the Area-Matching Label. Others like OBS are actually an issue with the installer, as the publisher doesn't update the version reported in the registry.
The version installed according to WinGET doesn't reflect the actual state for a number of applications. For example Discord has a newer version after auto-updating, then when running the installer. This makes the 'update' actually a downgrade.
This is another interesting point and I'm glad you brought it up. This definitely isn’t a good behavior, and it seems it is also caused by discord's auto update not updating the version in the registry. I'll take a look and see if the Discord manifest is set to require explicit upgrade to help prevent this issue.
WinGET update is reporting version that aren't applicable to my system that it aware of. It does report this when trying to actually update/install, but still does report the update as available
This is an interesting artifact of how the upgrade flow is implemented and has resulted in other errors too like count of packages with unknown version being incorrect. The way the upgrade check works is by seeing if there is any manifest for the package with a version that is higher than what is currently installed, no filters are applied for OS Verison, OS Architecture, or previous installer types. When the upgrade is executed though, it does go through those filters which results in that very frustrating message. @denelon - Perhaps a separate issue should be created to filter out inapplicable updates in all areas of the upgrade flow?
When I'm running with --silent, I do not expect to get any UAC prompts. If an application requires Elevated Permissions, it should be skipped when not already running elevated.
I know @denelon has been working with the team to make improvements by trying to reason about how the elevationRequired, elevatesSelf, and elevationProhibited properties can be used to address this behavior - either through providing a single UAC prompt at the beginning of the install flow, de-elevating as needed, etc. Part of the problem though, is that many of the packages don’t have these properties specified, which makes it very difficult to know if or when a package will throw a UAC prompt. The cases where you saw the warning of the UAC, someone took the time to specify the elevation property of the installers and add in the message.
Thank you for all the great feedback! I know its frustrating when things don’t work quite as they are supposed to or in the way you would expect.
Interesting. I see it in the screenshot you shared as
-u,--unknown,--include-unknown, right below-r,--recurse,--all.
I've read, checked, and double-checked the help page.. Can't understand how I've missed that one.. Sorry ^^
Thank you for all the great feedback! I know its frustrating when things don’t work quite as they are supposed to or in the way you would expect.
Don't worry, I know this is WIP and things cannot improve without feedback. Seeing the community working on this makes it worth posting the feedback in the first place. Even now WinGET already helps me so much!
@Master-Guy,
We released WinGet 1.7 with a few improvements. We're also working on the PowerShell module. We had a hiccup with the UI.Xaml 2.8 dependency, but that seems to have been largely resolved (not completely though).
I'm digging deep in the old bugs to review and see if any of them can be resolved. It's tedious work, but it's worth doing to try and keep the backlog clean. 😊
Hi @denelon
According to winget -v, I'm now on 1.8.532-preview.
If you want, I can go ahead and do another run of updates and report the results :)