winget-cli: Upgrade doesn't work for several packages
Edited:
The most common reasons upgrades don’t work has to do with how we match an installed application against a manifest in a configured source. We are depending on data available in Windows Apps & Features to match a manifest based on the “displayName” and “version”. In many cases there are multiple packages with data similar enough to make it unclear which manifest matches to an installed package.
We are working to improve the matching heuristic so we can distinguish between packages with a true update vs. packages that have a similar name and newer versions are installed “side by side”.
Original issue:
Upgrade didn’t work for PowerToys.
I have all of the experimental features enabled.
PS C:\Users\denelon> winget upgrade
Name Id Version Available Source
----------------------------------------------------------------------------
Microsoft Whiteboard Microsoft.Whiteboard 21.10111.5555.0 Latest msstore
HyperLabel SixgillLLC.hyperlabel 1.1.10.0 Latest msstore
PowerToys Microsoft.PowerToys 0.31.1 0.31.2 winget
PS C:\Users\denelon> winget uprade Microsoft.PowerToys
Windows Package Manager v0.2.10191 Preview
Copyright (c) Microsoft Corporation. All rights reserved.
PS C:\Users\denelon> winget list Power
Name Id Version Available Source
--------------------------------------------------------------------------------------------
PowerToys Microsoft.PowerToys 0.31.1 0.31.2 winget
PowerShell 7-x64 {41D89B69-B90A-4CFB-9783-4B86D2B34EC3} 7.1.1.0
PowerShell 7-preview-x64 {7DDB4F02-04AE-48FA-BC1D-962D3A567FF6} 7.1.0.5
Windows Terminal Preview Microsoft.WindowsTerminalPreview 1.6.10272.0
Windows Terminal Microsoft.WindowsTerminal 1.5.10271.0
PS C:\Users\denelon> winget upgrade Microsoft.PowerToys
--------------------------------------------------------------------------------------------
Found PowerToys [Microsoft.PowerToys]
No applicable update found.
PS C:\Users\denelon> winget --info
--------------------------------------------------------------------------------------------
Windows Package Manager v0.2.10191 Preview
Copyright (c) Microsoft Corporation. All rights reserved.
Windows: Windows.Desktop v10.0.19042.804
Package: Microsoft.DesktopAppInstaller v1.11.10191.0
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Reactions: 39
- Comments: 143 (63 by maintainers)
This issue has become a bit of a “mega-thread”. I’ll be creating discrete issues for the remaining items so they can be broken out and resolved. This will happen after we release the 1.2 dev build (coming soon [TM]).
This issue was created as a placeholder to track the more generic
winget upgrade <package>
doesn’t work.Many improvements have been made in Windows Package Manager 1.3 to address these issues.
In some cases, it’s related to the matching logic used to detect which packages match an installed application. We’ve implemented several improvements to matching and added Windows Apps & Features data to the schema.
In others, it’s related to the scope of the installed program and the scope the user is in. We’ve implemented a key in the manifest to inform users when they will need to elevate.
Still others are related to nested installers. We can now identify an MSI inside of an EXE based installer.
Now that the majority of use cases are known, I’m going to close this Issue in favor of tracking the specific issues that are causing the problem, and if the issue is related to the installer itself, it will be moved to winget-pkgs.
@AdamJel this is a fantastic summary of what you and others encountering. We have a couple of changes in flight to help address a subset of these issues. The ones that remain are directly related to how the Windows Package Manager attempts to match a manifest for a package with an installed App as reported in Windows via Apps & Features.
Once the changes are released for what we’re addressing in the first 1.2 preview build, I will likely come back to close this issue. I will then pull out the remaining issues into discrete things we need to fix. Thank you for being so thorough here.
Is upgrade work for other apps? I have the same problem with powertoys and other apps. No one successful upgrade. But upgrade knows about the newer version.
Another data point: with the most recent version of winget, GitHub CLI (shipped as an MSI) can’t be upgraded:
But if you run
winget install gh
, it installs correctly over the old version:Does upgrade run the installers with different command line arguments than install?
The v1.1 schema is considered “non-breaking”. The 1.0 schema will still work. The new schema will have the newer fields, but they are all optional. We’re expecting the benefits will be worth adding the optional fields, and the tooling (YamlCreate.ps1 and wingetcreate.exe) will be updated to support the enhanced fields. Newer versions of the client will take advantage of the new fields, and existing 1.x versions of the client will not break (although they wont be able to take advantage of some of the newer values). We plan on building a mechanism for the client to suggest an update to the user once new fields or schema versions have been detected. There is some fairly complex sequencing involved, but that is the goal.
Once the schema is released, we will begin upgrading the validation infrastructure with better guidance and information on how to generate better / more accurate manifests for packages. Our automation will continue scanning manifests daily. We will be able to automate adding some of the optional fields as they are detected/verified by the validation infrastructure so we can automatically improve manifests over time. Some fields will still likely need human intervention, but nothing prevents the community from making those improvements to older manifests.
This will be more of a gradual roll-out as compared with the v0.2 - 1.0 schema where we had to upgrade all manifests. Our goal is to keep the repository of existing packages healthy and functional as we roll out improvements.
Most likely if you are seeing
list
or rawupgrade
commands showing an upgrade available, butupgrade --all
orupgrade foo
is not doing anything, the issue will be fixed by #904 . I’m sure @denelon will be hot on my heels to get a build out too 😄The same situation. The output is the same as in example with java above.
i can’t upgrade gh cli, it says it was successfully upgraded, but if you check the version installed it is still the old one
I can confirm there are major improvements to the behaviour. Thanks for the persistence and solving them.
It’s now renamed to
winget.exe
I have just a little different issue with upgrade python. The problem is, I cannot select specific python to upgrade, which results in not upgrading python at all.
The same goes for uninstalling. Just replace
upgrade
withuninstall
. (Does not) Works the same.Versions:
Windows: Windows 10 Pro, 21H1, 19043.1320, Windows Feature Experience Pack 120.2212.3920.0
Terminal: 1.11.2921.0
winget: v1.1.12653
python3.9:
C:\Python39
python3.10:
~\AppData\Local\Programs\Python\Python310
installed with winget by IdSteps to reproduce:
notes
I wanted to try, what will upgrading python 3.9 do, since I want to have both versions - 3.9 and 3.10. So I was wandering, if winget respects this or not.
uninstall
Also, uninstalling is a little confusing:
It seems, that winget is uninstalling the Python.Python.3, which seems to be the 3.9 version. But it actually uninstalled the 3.10 version. Little confusing.
install
Also, I am a little confused from install command results.
First I try the obvious:
Ok, so there is some strange Metro Python. No problem, I just refine my input as suggested:
Hmm, refined input didnt work and furthermore responded with even more options. Ok, this could be because I didnt specified the
name
flag. Also, lets be specific on the version. Lets try again:Hmmmm, do I really have to install only by
id
? I want to install python, this should be painless… (btw Windows is full of bloatware, but python is still not preinstalled?)Oh no. This gets really frustrating. Also, notice the
Version Unknown
on second line 😃 I would swear I already removed the msstore as a source. Does upgrading the winget silently adds the msstore as a source??? Anyway:Finally, a decent installation of python. Now, because the bleeding edge won’t suffice, lets install the 3.9 version as well.
Huraaay. Lets see, if winget upgrade is ok with both versions.
Oh nooo. Just where I started. What am I doing wrong? What is winget doing wrong? Why are we so incompatible? I don’t recollect any of this hassle from when I was using the Chocolatey.
We’ve isolated most of the issues reported for upgrade. The v1.1 schema work should address the vast majority of these.
Related to:
There is a weird bug after upgrading the package there winget upgrade shows still update available. Also winget upgrade --all doesn’t upgrade all packages available.
PowerToys and some other packages have an additional complication. The
InstallerType
is a .exe, but the installer does some required setup work an extracts an MSI for the actual install. We’re talking about additional work to support this scenario. We check to make sure the installer is the same type to avoid other complications related to switching the installer type for the upgrade scenario.A little update for everyone in the thread, most of these issues should be resolved in Windows Package Manager 1.3.432-preview
The Packages i could found in this thread with remaining issues
We would love to know about any other application with issues, please make your issues here https://github.com/microsoft/winget-pkgs/issues with a relevant title, (
<PackageID> - Side-By-Side installation
orNo applicable update found.
)That should be coming soon™: #1537.
I can confirm that, for me, when running winget in Windows Terminal in non-administrator mode
winget upgrade
shows a list of programs with a current “Version” and an “Available” version.winget upgrade --all
purports to download and install those programs.winget upgrade
again shows the same list with the same value under “Version” and “Available”. That is, as if the previous command had no effect at all.I can confirm that, for me, when running winget in Windows Terminal in administrator mode that problem disappears.
The range of possible solutions would include:
winget upgrade
and/orwinget upgrade --all
) is run non-administrator mode then halt the command and return an error message like “winget must be run in administrator mode”; orwinget upgrade --all
to allow it to install those programs that can be installed under non-administrator mode and flag those programs that can’t as “requires administrator mode”.Versions: Winget: v1.1.12653 Windows: Windows 10 Pro, 21H1, 19043.1288 Windows Terminal Preview: 1.12.2931.0
Thanks. Clear explanation. The other packages listed in my screenshot suffer from the un-upgradable issue as well. Hopefully, winget 1.1 will mitigate that problem.
@Karl-WE we haven’t found the “hard and fast” set of rules/behaviors for all of them.
We’re aware of many different issues related to upgrade, and the vast majority of them are a combination of either the version reported in Apps & Features or the installer type used for the original install vs. the installer type in the manifest.
You can do “one issue per package” in the winget-pkgs repository to see if the community can figure out what’s wrong and fix the manifest(s), and if it’s a client issue, we can link them to Issues here.
Many should start being cleaned up once we get the v1.1 schema released. We’re abstracting the fields used for matching in the new schema which addresses most of them. The one scenario we aren’t able to resolve with the changes is when the package doesn’t report any version to Windows.
Winget version - v1.0.11692 Build tools upgrade problem
@pocki also like your idea, the only thing that can / will happen are duplicate apps. see above had a lot of issues with 7zip because it was installed with the exe and then with winget. it will not play nicely on uninstall / upgrades. If you create a FR please ping me there. I think it should include a method that winget upgrade is listing the current installer and the one that is in winget in columns and raise a warning.
OT: Maybe once dependencies are available, we could ask the PowerToys team nicely for the extracted MSI and install the dependencies (.NET Core Desktop Runtime I think) via WinGet so we could make that specific app less complex. And iTunes is available via the Microsoft Store, so we can make that app less complex that way.
iTunes (Apple.iTunes) doesn’t upgrade (I don’t know if it is just because it’s an exe or…), and WinGet doesn’t even try, although it knows there’s an upgrade available.
Additional examples, both from microsoft: Microsoft.Teams - Installer failed with exit code: 1603 Microsoft.dotnetRuntime - upgrade was successful, but i still have an old version
This is primarily driven by “list”. The way packages in Add/Remove Packages are mapped to package identifiers in the Windows Package Manager is fairly complex. Generally MSIX packages contain enough meta-data that it is trivial to get a match. Unfortunately, other legacy installers often don’t have enough meta-data. We’re working on improving list gradually, and we’re thinking through several different heuristics to increase the number of matches.
Thanks for the additional data points here. Some applications work “Microsoft.WindowsTerminalPreview” and “Microsoft.WindowsTerminal” while others don’t.
Powertoys - the same as author of this issue. After
winget install powertoys
i receive new version.PythonSoftwareFoundation.Python from msstore - No applicable update found. AdoptOpenJDK.OpenJDK - Successfully installed, but after installation i have the same old version. It was installed through winget.
Full log
Still having issues upgrading packages. These packages are constantly showing up as needing upgrades, but they are all ready up to date::
PS C:\Windows\System32> winget upgrade --all Name Id Version Available Source
Winamp Radionomy.Winamp 5.8 5.8 winget Python 3.10.4 (64-bit) Python.Python.3 < 3.10.5 3.10.4150.0 winget Microsoft ASP.NET Core 6.0.6 - Shared Framework (x86) Microsoft.DotNet.AspNetCore.6 6.0.6 6.0.7 winget Microsoft Windows Desktop Runtime - 6.0.6 (x86) Microsoft.DotNet.DesktopRuntime.6 6.0.6 6.0.7 winget Microsoft .NET SDK 6.0.203 (x64) Microsoft.DotNet.SDK.6 6.0.203 6.0.302 winget 5 upgrades available.
(1/5) Found Winamp [Radionomy.Winamp] Version 5.8 This application is licensed to you by its owner. Microsoft is not responsible for, nor does it grant any licenses to, third-party packages. Downloading https://download.nullsoft.com/winamp/misc/winamp58_3660_beta_full_en-us.exe ██████████████████████████████ 7.82 MB / 7.82 MB Successfully verified installer hash Starting package install… Successfully installed
(2/5) Found Python 3 [Python.Python.3] Version 3.10.4150.0 This application is licensed to you by its owner. Microsoft is not responsible for, nor does it grant any licenses to, third-party packages. Downloading https://www.python.org/ftp/python/3.10.4/python-3.10.4-amd64.exe ██████████████████████████████ 27.1 MB / 27.1 MB Successfully verified installer hash Starting package install… Successfully installed
(3/5) Found Microsoft ASP.NET Core Runtime 6.0 [Microsoft.DotNet.AspNetCore.6] Version 6.0.7 This application is licensed to you by its owner. Microsoft is not responsible for, nor does it grant any licenses to, third-party packages. Downloading https://dotnetcli.azureedge.net/dotnet/aspnetcore/Runtime/6.0.7/aspnetcore-runtime-6.0.7-win-x64.exe ██████████████████████████████ 8.58 MB / 8.58 MB Successfully verified installer hash Starting package install… Successfully installed
(4/5) Found Microsoft .NET Windows Desktop Runtime 6.0 [Microsoft.DotNet.DesktopRuntime.6] Version 6.0.7 This application is licensed to you by its owner. Microsoft is not responsible for, nor does it grant any licenses to, third-party packages. Downloading https://dotnetcli.azureedge.net/dotnet/WindowsDesktop/6.0.7/windowsdesktop-runtime-6.0.7-win-x64.exe ██████████████████████████████ 55.0 MB / 55.0 MB Successfully verified installer hash Starting package install… Successfully installed
(5/5) Found Microsoft .NET SDK 6.0 [Microsoft.DotNet.SDK.6] Version 6.0.302 This application is licensed to you by its owner. Microsoft is not responsible for, nor does it grant any licenses to, third-party packages. Downloading https://dotnetcli.azureedge.net/dotnet/Sdk/6.0.302/dotnet-sdk-6.0.302-win-x64.exe ██████████████████████████████ 196 MB / 196 MB Successfully verified installer hash Starting package install… Successfully installed
PS C:\Windows\System32> PS C:\Windows\System32> winget upgrade Name Id Version Available Source
Winamp Radionomy.Winamp 5.8 5.8 winget Python 3.10.4 (64-bit) Python.Python.3 < 3.10.5 3.10.4150.0 winget Microsoft ASP.NET Core 6.0.6 - Shared Framework (x86) Microsoft.DotNet.AspNetCore.6 6.0.6 6.0.7 winget Microsoft Windows Desktop Runtime - 6.0.6 (x86) Microsoft.DotNet.DesktopRuntime.6 6.0.6 6.0.7 winget Microsoft .NET SDK 6.0.203 (x64) Microsoft.DotNet.SDK.6 6.0.203 6.0.302 winget 5 upgrades available. PS C:\Windows\System32> exit
C:\Windows\System32>
Of course I understand what a bona fide hash mismatch is, and why such a situation would cause WinGet to throw an error, but I have a feeling that the root cause is something else in this case.
This particular issue has persisted for several months now, and if I try to invoke WinGet against this id with the
install
option (with all Office applications closed), I getThe installation reports success, but subsequent checks don’t seem to verify that. Others have reported similar issues. If I do
winget show Microsoft.Office
, I getI can download
setup.exe
from that URL listed near the bottom, and running it has the same result: the installation reports success, but the version(s) don’t change. And, by the way, I can use PowerShell to check the file integrity using the hash listed on the last line of the above output:(Get-FileHash setup.exe).Hash
does indeed confirm this.grepWin issue is because it places its installation files in
C:\Users\%USERNAME%\AppData\Local\Programs\grepWin\grepWin.exe
(current user) but the registry entry is inComputer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{0F4D121B-B2A5-4B61-944D-4274837F24B4}
(all users) so it shows up in the Control Panel for all users.So it’s one of those scope vs registry entries issues.
Haven’t found similar issue in qBittorrent repo, so opened one myself: https://github.com/qbittorrent/qBittorrent/issues/16764
Cannot replicate the Authy issue
Log snippet from what it does when "upgrading"
You should check this log
%LOCALAPPDATA%\SquirrelTemp\SquirrelSetup.log
Alternative log:%LOCALAPPDATA%\Temp\SquirrelSetup.log
Noticed that Microsoft C++ 2015-2019 might not get upgraded to latest C++ 2015-2022 for only one of both architectures. This is because @ItzLevvie2 added 2015-2019 upgrades.
current behaviour: So sometimes architecture e.g., x64 gets correctly upgraded from 2015-2019 to latest 2015-2022 and the other arch will be unreproducible upgraded to the latest 2015-2019 only.
expected behaviour: All 2015-2019 x64 and x86 should be upgraded to 2015-2022.
suggestion: remove or correct the upgrade path in: https://github.com/microsoft/winget-pkgs/tree/master/manifests/m/Microsoft/VC%2B%2B2015-2019Redist-x86 https://github.com/microsoft/winget-pkgs/tree/master/manifests/m/Microsoft/VC%2B%2B2015-2019Redist-x64
I have a problem upgrading Intel Driver utility. Running winget upgrade tell me that
Intel.IntelDriverAndSupportAssistant
has a new version. If I try to upgrade that using the id, it tell me that there are multiple packages and one of them have a total different id).Hi @denelon does this include the detection? Often I face inconsistent upgrade detection for existing package incl. C++ Redist 2015-2022, on some system it works fine and on some not. Also other apps affected workaround: manually upgrade with Winget install applicationname.
I have one more case. It shows unknown version, just after installing the package (Toggl.TogglDesktop)
Steps to reproduce:
Awesome, cannot wait to try.
@Karl-WE Maybe you should take a look at wingetcreate. So far it’s pretty helpful, although not a GUI.
Thank you @denelon I see a lot of good progress from you and the team. Keep it up!
Thanks for the update @Karl-WE. We’re still working on what kinds of behavior we can build to deal with installers that don’t report a version in Apps & Features. There is still a lot of work to try and meet developers where they are.
This sounds very solid, thank you very much for the detailed information!
denelon is currently unavailable this week. I’ll go ahead and tag @KevinLaMS
Hi @denelon still actively and broadly using the current release of Winget and still facing issues with --upgrade on different packages. They do install but remain in the --upgrade list as if they are not (correctly) upgraded. How is it supposed to handle this in github. Bugreport for each? @KevinLaMS
@denelon @crutkas as outlined on Twitter. Winget upgrade will offer to upgrade .net Core 3.1.x to 5.x https://dotnet.microsoft.com/download/dotnet/3.1 https://dotnet.microsoft.com/download/dotnet/5.0
Unfortunately PowerToys will fail to work with the new .net Core 5.x Additionally on upgrade 5.0 will be installed side by side (3.x will not be properly removed in apps)
issues:
Windows Desktop: 21H1, current Winget version / app installer 09/04/2021: this is fixed now.
After using winget for a few weeks, I also have a ton of packages, that show available upgrades, but don’t upgrade “No Applicable Update Available”. Or they do upgrade, but somehow end on being the same version as before.
Basically for all of the following packages upgrading is not working:
Running
winget upgrade --all
results in winget trying to upgrade Python.Python.3 and Microsoft.dotnetRuntime. After the (successfull) installation, those 2 packages are still showing available upgrades:I am not sure if this is the correct place to report “faulty” packages.
I created a FR #1094 @Karl-WE, @denelon please feel free to add your ideas and informations
@Karl-WE go ahead and create a new issue in the winget-pkgs repository as a “Bug Report”. I’ll put the “Help-Wanted” label on it so someone from the community can take a look to see what might be doable in terms of modifying the manifest initially.
@Karl-WE we’re still working through the best process to address packages with
winget upgrade
challenges. It seems to be a combination of the reported publisher, package, and version coming from Add / Remove Programs and how those values align to what is in a manifest. I’m thinking about creating a new “Issue” template in the winget-pkgs repository to reportupgrade
failures.I have the same issue for the Oracle.VirtualBox and Mozilla.Firefox packages. They both show available updates, but updating them doesn’t work with
winget upgrade --all
. Also doesn’t work updating them one by one. Hope it’s okay if I just drop this here:@pocki in your example, my guess is that Gridcoin and Microsoft MPI are either a different installer type that what was used for the original install.
Adobe and Visual Studio Code are reporting a different version in the manifest from what gets installed. I’ve seen a PR to address Visual Studio Code, but I don’t know if anybody has done the same thing for Adobe. In Adobe’s case, one needs to add the manifest with the matching version number(s) and remove the manifests with the non matching ones (multiple PRs, add first then delete one at a time as we only validate one manifest pr PR).
Windows Package Manager v1.0.11451 Copyright © Microsoft Corporation. Alle Rechte vorbehalten.
Windows: Windows.Desktop v10.0.19041.985 Paket: Microsoft.DesktopAppInstaller v1.11.11451.0
Upgrades for VCRedist2015-2019 x64 / x86 are not recognized by winget upgrade may also affect other redist packages available packages
installed packaged
result
result manual upgrade
added seperated issue #1093
@Karl-WE go ahead and create a new issue in the winget-pkgs repository as a “Bug Report”. I’ll put the “Help-Wanted” label on it so someone from the community can take a look to see what might be doable in terms of modifying the manifest initially.
_Originally posted by @denelon in https://github.com/microsoft/winget-cli/issues/752#issuecomment-853176927_
issue in winget repository: https://github.com/microsoft/winget-pkgs/issues/16011
indows Package Manager v0.4.11391 Microsoft Store Support Deactivated experimentalMSStore
Packages that cause troubles:
Someone changed the version in the YAML from 21.02 alpha to 21.02 alpha
issue: Winget will cause issues on upgrades when detecting an application that has been installed with a different installer and will install twice. It cannot (by design) uninstall the other application and thus it won’t get removed from the upgrade app
first entry winget MSI
second entry
manual install (exe) recognized by winget upgrade
This will also happen with other apps like Teams Teams-wide installer, or PDF24 EXE vs MSI etc. proposal: It is not basically a problem of winget that this happens, but maybe it could be good to check if the installer type changes?
erratum: It seems even with uninstalling both apps it will remain in winget upgrade. It seems there is a corruption because the MSI app DisplayName has changed too.
uninstaller strings: 7-Zip 21.02 (x64 edition) MsiExec.exe /X{23170F69-40C1-2702-2102-000001000000}
7-Zip 21.02 alpha (x64) Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\7-Zip
After manually purging the registry, all fine. Futher observation (goes a bit beyond the scope of issue discussed here): winget had also issues to uninstall them Even with the correct name it pretends the name is not matching even using -e but factually they don’t have the same name or the same ID.
reference: #976 also mentions about issues with 7zip alpha.
Windows Package Manager v0.4.11391 Microsoft Store Support Deactivated experimentalMSStore
Packages that cause troubles: Malwarebytes.Malwarebytes
issue: will stuck at downloading 0%
winget install does not work either, maybe the YAML is broken? proposal: implement a download timeout (e.g. 30 seconds)