winget-cli: Upgrade doesn't work for several packages

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:

PS C:\Users\Easton Pillay\projects\winget-pkgs\manifests\g\GitHub\cli> winget upgrade --all
Found GitHub CLI [GitHub.cli]
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://github.com/cli/cli/releases/download/v1.8.1/gh_1.8.1_windows_amd64.msi
  ██████████████████████████████  6.56 MB / 6.56 MB
Successfully verified installer hash
Starting package install...
Successfully installed
   
PS C:\Users\Easton Pillay\projects\winget-pkgs\manifests\g\GitHub\cli> gh --version            
gh version 1.8.0 (2021-03-30)
https://github.com/cli/cli/releases/tag/v1.8.0
PS C:\Users\Easton Pillay\projects\winget-pkgs\manifests\g\GitHub\cli> 

But if you run winget install gh, it installs correctly over the old version:

PS C:\Users\Easton Pillay\projects\winget-pkgs\manifests\g\GitHub\cli> winget install gh
Found GitHub CLI [GitHub.cli]
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://github.com/cli/cli/releases/download/v1.8.1/gh_1.8.1_windows_amd64.msi
  ██████████████████████████████  6.56 MB / 6.56 MB
Successfully verified installer hash
Starting package install...
Successfully installed
PS C:\Users\Easton Pillay\projects\winget-pkgs\manifests\g\GitHub\cli> gh --version
gh version 1.8.1 (2021-04-02)
https://github.com/cli/cli/releases/tag/v1.8.1
PS C:\Users\Easton Pillay\projects\winget-pkgs\manifests\g\GitHub\cli> 

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 raw upgrade commands showing an upgrade available, but upgrade --all or upgrade 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 😄

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

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.

I installed this version and AppInstallerCLI.exe is gone?

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 with uninstall. (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 Id

Steps to reproduce:

1. > winget upgrade
   Name                             Id                                Version              Available            Source
   -------------------------------------------------------------------------------------------------------------------
   Python 3                         Python.Python.3                   3.9.7150.0           3.10.150.0           winget
   

2. ❯ winget upgrade "Python 3" -h
   Multiple installed packages found matching input criteria. Please refine the input.
   Name                   Id
   -------------------------------------------------------------
   Python 3               Python.Python.3
   Python 3.10.0 (64-bit) {21b42743-c8f9-49d7-b8b6-b5855317c7ed}
   

3. ❯ winget upgrade --id "Python.Python.3" -h
   Multiple installed packages found matching input criteria. Please refine the input.
   Name                   Id
   -------------------------------------------------------------
   Python 3               Python.Python.3
   Python 3.10.0 (64-bit) {21b42743-c8f9-49d7-b8b6-b5855317c7ed}
   

4. ❯ winget upgrade --name "Python 3" -h
   Multiple installed packages found matching input criteria. Please refine the input.
   Name                   Id
   -------------------------------------------------------------
   Python 3               Python.Python.3
   Python 3.10.0 (64-bit) {21b42743-c8f9-49d7-b8b6-b5855317c7ed}
   

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:

~ ❯ winget uninstall --id "Python.Python.3"
Multiple installed packages found matching input criteria. Please refine the input.
Name                   Id
-------------------------------------------------------------
Python 3               Python.Python.3
Python 3.10.0 (64-bit) {21b42743-c8f9-49d7-b8b6-b5855317c7ed}

~ ❯ winget uninstall --name "Python 3.10.0 (64-bit)"
Found Python 3 [Python.Python.3]
Starting package uninstall...
Successfully uninstalled

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:

~ ❯ winget install "Python 3"
Multiple packages found matching input criteria. Please refine the input.
Name               Id              Source
------------------------------------------
Python 3 For Metro 9WZDNCRDCNG1    msstore
Python 3           Python.Python.3 winget

Ok, so there is some strange Metro Python. No problem, I just refine my input as suggested:

~ ❯ winget install --name "Python 3"
Multiple packages found matching input criteria. Please refine the input.
Name                                                                                        Id              Source
-------------------------------------------------------------------------------------------------------------------
Python 3 For Metro                                                                          9WZDNCRDCNG1    msstore
Python 3.9                                                                                  9P7QFQMJRFP7    msstore
Python 3.8                                                                                  9MSSZTT1N39L    msstore
Python 3.7                                                                                  9NJ46SX7X90P    msstore
Python 3.10                                                                                 9PJPW5LDXLZ5    msstore
Introduction to Python Programming by GoLearningBus                                         9NBLGGH6FLKH    msstore
Learn Django and Python by GoLearningBus                                                    9WZDNCRDN82R    msstore
Python Programs                                                                             9WZDNCRDMNF6    msstore
Fréquence 3                                                                                 9NBLGGGZJRTF    msstore
CRO Exchange Rates                                                                          9WZDNCRDMDPT    msstore
Practice Session                                                                            9NBLGGH3SM2P    msstore
Notepad Editor                                                                              9NBLGGH6B82Z    msstore
InstantPython                                                                               9WZDNCRDC1W5    msstore
MuffinPy                                                                                    9N67N0G212C0    msstore
Switch Case Generator                                                                       9N375S1MHVXL    msstore
#Code                                                                                       9NBLGGH4S3MF    msstore
BlockCode 少儿编程                                                                          9P865HPC6M9Z    msstore
DarkMoonX                                                                                   9PJ369WKBV7F    msstore
Npzee                                                                                       9N19KHP7G2P4    msstore
Quantyl Discovery - Data Visualization - Data Analysis - Presentation with interactive gra… 9N22FJ23KDG0    msstore
Python 3                                                                                    Python.Python

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:

~ ❯ winget install --name "Python 3.9"
Multiple packages found matching input criteria. Please refine the input.
Name                                                                                           Id           Source
-------------------------------------------------------------------------------------------------------------------
Python 3.9                                                                                     9P7QFQMJRFP7 msstore
Python 3.8                                                                                     9MSSZTT1N39L msstore
Python 3.7                                                                                     9NJ46SX7X90P msstore
Python 3.10                                                                                    9PJPW5LDXLZ5 msstore
Notepad Editor                                                                                 9NBLGGH6B82Z msstore
InstantPython                                                                                  9WZDNCRDC1W5 msstore
MuffinPy                                                                                       9N67N0G212C0 msstore
Introduction to Python Programming by GoLearningBus                                            9NBLGGH6FLKH msstore
Learn Django and Python by GoLearningBus                                                       9WZDNCRDN82R msstore
Switch Case Generator                                                                          9N375S1MHVXL msstore
Python Programs                                                                                9WZDNCRDMNF6 msstore
#Code                                                                                          9NBLGGH4S3MF msstore
DarkMoonX                                                                                      9PJ369WKBV7F msstore
BlockCode 少儿编程                                                                             9P865HPC6M9Z msstore
Npzee                                                                                          9N19KHP7G2P4 msstore
Quantyl Discovery - Data Visualization - Data Analysis - Presentation with interactive graphi… 9N22FJ23KDG0 msstore
Cars Tuning Games                                                                              9NZS5213HLJQ msstore
SPL                                                                                            9NF9TNCG82P1 msstore
العبقرى                                                                                        9NBLGGH1RNS9 msstore
Play With Regex                                                                                9NHP7J7BGT

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?)

~ ❯ winget install --id "9P7QFQMJRFP7"
Found Python 3.9 [9P7QFQMJRFP7] Version Unknown
...
The publisher requires that you view the above information and accept the agreements before installing.
Do you agree to the terms?
[Y] Yes  [N] No: yes
Verifying/Requesting package acquisition...
Verifying/Requesting package acquisition failed: no store account found

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:

~ ❯ winget source remove msstore
Removing source: msstore...
Done

~ ❯ winget install --name 'Python 3' -h
Found Python 3 [Python.Python.3] Version 3.10.150.0
...
Successfully installed

Finally, a decent installation of python. Now, because the bleeding edge won’t suffice, lets install the 3.9 version as well.

~ ❯ winget install --name "Python 3" --version 3.9.7150.0 -h
...
Successfully installed

Huraaay. Lets see, if winget upgrade is ok with both versions.

~ ❯ winget upgrade
Name                             Id                                Version              Available            Source
----------------------------------------------------------------------------------------------
Python 3                         Python.Python.3                   3.9.7150.0           3.10.150.0           winget

~ ❯ winget upgrade "Python 3"
Multiple installed packages found matching input criteria. Please refine the input.
Name                   Id
-------------------------------------------------------------
Python 3               Python.Python.3
Python 3.10.0 (64-bit) {21b42743-c8f9-49d7-b8b6-b5855317c7ed}

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:

• #1243
• #713
• #1073
• #1145
• #1163
• #1242
• #1284

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.

PS C:\Users\surya> winget upgrade
Name               Id                         Version     Available         Source
----------------------------------------------------------------------------------
Zoom               Zoom.Zoom                  5.6.5 (823) 5.6.961           winget
Visual Studio Code Microsoft.VisualStudioCode 1.56.2      1.56.2.054a929533 winget
PS C:\Users\surya> winget upgrade --silent --all
Found Visual Studio Code [Microsoft.VisualStudioCode]
This application is licensed to you by its owner.
Microsoft is not responsible for, nor does it grant any licences to, third-party packages.
Downloading https://az764295.vo.msecnd.net/stable/054a9295330880ed74ceaedda236253b4f39a335/VSCodeUserSetup-x64-1.56.2.exe
  ██████████████████████████████  76.3 MB / 76.3 MB
Successfully verified installer hash
Starting package install...
Successfully installed

PS C:\Users\surya> winget upgrade
Name               Id                         Version     Available         Source
----------------------------------------------------------------------------------
Zoom               Zoom.Zoom                  5.6.5 (823) 5.6.961           winget
Visual Studio Code Microsoft.VisualStudioCode 1.56.2      1.56.2.054a929533 winget

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

• Unknown versions are optional and forced with a flag
• AppsAndFeaturesEntries solves the Installer in the Installer issue

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 or No applicable update found.)

• Check if your issue is not already resolved
• 1 issue for each Package
• No duplicates
• Include your log from winget --info

Fix winget 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”.

That should be coming soon™: #1537.

I can confirm that, for me, when running winget in Windows Terminal in non-administrator mode

• Running winget upgrade shows a list of programs with a current “Version” and an “Available” version.
• Running winget upgrade --all purports to download and install those programs.
• Running 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:

• When winget (or perhaps just for winget upgrade and/or winget upgrade --all) is run non-administrator mode then halt the command and return an error message like “winget must be run in administrator mode”; or
• Fix winget 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

Below is the list of packages that refuse to recognize an upgrade command when one is run. I broke out Bulk Rename Utility to illustrate how winget can’t parse its current version # in a list view, yet it can clearly read its version number in show. Obviously, the current version # is present somewhere in the installed BRU package.

The reason for this is because the version from winget upgrade or winget list relies on the information from the ARP (Add / Remove Programs) in the control panel.

It displays in winget show because the version has been added to the manifest and that’s where it fetches from.

The ideal solution is to request the publisher of the software to add a version to the installer/program.

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.

PS C:\Users\Easton Pillay\projects\winget-pkgs> winget upgrade
Name   Id           Version    Available  Source
------------------------------------------------
iTunes Apple.iTunes 12.11.0.26 12.11.3.17 winget
PS C:\Users\Easton Pillay\projects\winget-pkgs> winget upgrade --all
No applicable update found.
PS C:\Users\Easton Pillay\projects\winget-pkgs>

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

PS C:\WINDOWS\system32> winget upgrade Name Id Version Available Source Microsoft Teams Microsoft.Teams 1.2.0.19260 1.4.00.8872 winget .NET Core Runtime Microsoft.dotnetRuntime 3.1.11.29516 5.0.5.29917 winget PS C:\WINDOWS\system32> winget upgrade --all Found Microsoft Teams [Microsoft.Teams] 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://statics.teams.cdn.office.net/production-windows-x64/1.4.00.8872/Teams_windows_x64.msi ██████████████████████████████ 106 MB / 106 MB Successfully verified installer hash Starting package install… Installer failed with exit code: 1603 Installer log is available at: C:\Users\Leanid_Miron\AppData\Local\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\DiagOutputDir\WinGet-Microsoft.Teams.1.4.00.8872-2021-04-23-14-49-29.696.log Found .NET Core Runtime [Microsoft.dotnetRuntime] 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.visualstudio.microsoft.com/download/pr/c1ef0b3f-9663-4fc5-85eb-4a9cadacdb87/52b890f91e6bd4350d29d2482038df1c/windowsdesktop-runtime-5.0.5-win-x64.exe ██████████████████████████████ 52.4 MB / 52.4 MB Successfully verified installer hash Starting package install… Successfully installed PS C:\WINDOWS\system32> winget upgrade Name Id Version Available Source Microsoft Teams Microsoft.Teams 1.2.0.19260 1.4.00.8872 winget .NET Core Runtime Microsoft.dotnetRuntime 3.1.11.29516 5.0.5.29917 winget

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

C:\Users\shatu> winget upgrade
Name                        Id                                  Version   Available Source
-------------------------------------------------------------------------------------------
Python 3.9                  PythonSoftwareFoundation.Python.3.9 3.9.496.0 Latest    msstore
AdoptOpenJDK 15.0.2+7 (x64) AdoptOpenJDK.OpenJDK                15.0.1.9  15.0.2.7  winget

PS C:\Users\shatu> winget upgrade --all
Found Python 3.9 [PythonSoftwareFoundation.Python.3.9]
This package is provided through Microsoft Store. winget may need to acquire the package from Microsoft Store on behalf of the current user.
Verifying/Requesting package acquisition...
Verifying/Requesting package acquisition success
Starting package install...
No applicable update found.

Found AdoptOpenJDK 15.0.2+7 (x64) [AdoptOpenJDK.OpenJDK]
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://github.com/AdoptOpenJDK/openjdk15-binaries/releases/download/jdk-15.0.2%2B7/OpenJDK15U-jdk_x64_windows_hotspot_15.0.2_7.msi
  ██████████████████████████████   167 MB /  167 MB
Successfully verified installer hash
Starting package install...
Successfully installed

PS C:\Users\shatu> winget upgrade
Name                        Id                                  Version   Available Source
-------------------------------------------------------------------------------------------
Python 3.9                  PythonSoftwareFoundation.Python.3.9 3.9.496.0 Latest    msstore
AdoptOpenJDK 15.0.2+7 (x64) AdoptOpenJDK.OpenJDK                15.0.1.9  15.0.2.7  winget

PS C:\Users\shatu> java -version
openjdk version "15.0.1" 2020-10-20
OpenJDK Runtime Environment AdoptOpenJDK (build 15.0.1+9)
OpenJDK 64-Bit Server VM AdoptOpenJDK (build 15.0.1+9, mixed mode, sharing)

PS C:\Users\shatu> winget -v
v0.2.10191 Preview

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 get

winget install --id=Microsoft.Office
Found Microsoft 365 Apps for enterprise [Microsoft.Office] Version 16.0.15330.20218
This application is licensed to you by its owner.
Microsoft is not responsible for, nor does it grant any licenses to, third-party packages.
Successfully verified installer hash
Starting package install...
Successfully installed

winget upgrade
Name                                      Id               Version          Available        Source
---------------------------------------------------------------------------------------------------
Microsoft 365 Apps for enterprise - en-us Microsoft.Office 16.0.14931.20604 16.0.15330.20218 winget
1 upgrades available.

The 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 get

Found Microsoft 365 Apps for enterprise [Microsoft.Office]
Version: 16.0.15330.20218
Publisher: Microsoft Corporation
Publisher Url: https://www.microsoft.com/
Publisher Support Url: https://support.office.com/
Author: Microsoft Corporation
Moniker: office
Description: Microsoft 365 Apps for enterprise is the most productive and most secure Office experience for enterprises, allowing your teams to work together seamlessly from anywhere, anytime.
Homepage: https://www.office.com/
License: Commercial
License Url: https://docs.microsoft.com/legal/termsofuse
Privacy Url: https://privacy.microsoft.com/
Copyright: Copyright (C) Microsoft Corporation
Copyright Url: https://docs.microsoft.com/legal/termsofuse
Installer:
  Type: exe
  Download Url: https://officecdn.microsoft.com/pr/wsus/setup.exe
  SHA256: fea967e44aed1cd406d2fe4f60f7199375fff30115864600c2da4dbf15425dde

I 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 in Computer\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

1. winget install Twilio.Authy -v 1.9.0
2. winget upgrade Twilio.Authy
3. winget install Twilio.Authy -v 1.9.0

2022-03-13 20:45:29> Program: Starting Squirrel Updater: --install . -s
2022-03-13 20:45:29> Program: Starting install, writing to C:\Users\User\AppData\Local\SquirrelTemp
2022-03-13 20:45:29> Program: About to install to: C:\Users\User\AppData\Local\authy
2022-03-13 20:45:29> Program: Install path C:\Users\User\AppData\Local\authy already exists, burning it to the ground
2022-03-13 20:45:29> CheckForUpdateImpl: Couldn't write out staging user ID, this user probably shouldn't get beta anything: System.IO.DirectoryNotFoundException: Could not find a part of the path 'C:\Users\User\AppData\Local\authy\packages\.betaId'.
   at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
   at System.IO.FileStream.Init(String path, FileMode mode, FileAccess access, Int32 rights, Boolean useRights, FileShare share, Int32 bufferSize, FileOptions options, SECURITY_ATTRIBUTES secAttrs, String msgPath, Boolean bFromProxy, Boolean useLongPath, Boolean checkHost)
   at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, FileOptions options, String msgPath, Boolean bFromProxy, Boolean useLongPath, Boolean checkHost)
   at System.IO.StreamWriter.CreateFile(String path, Boolean append, Boolean checkHost)
   at System.IO.StreamWriter..ctor(String path, Boolean append, Encoding encoding, Int32 bufferSize, Boolean checkHost)
   at System.IO.File.InternalWriteAllText(String path, String contents, Encoding encoding, Boolean checkHost)
   at System.IO.File.WriteAllText(String path, String contents, Encoding encoding)
   at Squirrel.UpdateManager.CheckForUpdateImpl.getOrCreateStagedUserId()
2022-03-13 20:45:29> CheckForUpdateImpl: Failed to load local releases, starting from scratch: System.IO.DirectoryNotFoundException: Could not find a part of the path 'C:\Users\User\AppData\Local\authy\packages\RELEASES'.
   at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
   at System.IO.FileStream.Init(String path, FileMode mode, FileAccess access, Int32 rights, Boolean useRights, FileShare share, Int32 bufferSize, FileOptions options, SECURITY_ATTRIBUTES secAttrs, String msgPath, Boolean bFromProxy, Boolean useLongPath, Boolean checkHost)
   at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share)
   at Squirrel.Utility.LoadLocalReleases(String localReleaseFile)
   at Squirrel.UpdateManager.CheckForUpdateImpl.<CheckForUpdate>d__2.MoveNext()
2022-03-13 20:45:29> CheckForUpdateImpl: Reading RELEASES file from C:\Users\User\AppData\Local\SquirrelTemp
2022-03-13 20:45:29> CheckForUpdateImpl: First run or local directory is corrupt, starting from scratch
2022-03-13 20:45:29> ApplyReleasesImpl: Writing files to app directory: C:\Users\User\AppData\Local\authy\app-2.0.0
2022-03-13 20:45:31> LogHost: Rigging execution stub for Authy Desktop_ExecutionStub.exe to C:\Users\User\AppData\Local\authy\Authy Desktop.exe
2022-03-13 20:45:31> ApplyReleasesImpl: Squirrel Enabled Apps: [C:\Users\User\AppData\Local\authy\app-2.0.0\Authy Desktop.exe]
2022-03-13 20:45:32> ApplyReleasesImpl: Starting fixPinnedExecutables
2022-03-13 20:45:32> ApplyReleasesImpl: Examining Pin: File Explorer.lnk
2022-03-13 20:45:32> ApplyReleasesImpl: Examining Pin: Microsoft Edge.lnk
2022-03-13 20:45:32> ApplyReleasesImpl: Fixing up tray icons
2022-03-13 20:45:32> ApplyReleasesImpl: cleanDeadVersions: for version 2.0.0
2022-03-13 20:45:32> ApplyReleasesImpl: cleanDeadVersions: exclude folder app-2.0.0

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:

winget install Toggl.TogglDesktop
winget upgrade

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!

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?

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:

• incomplete upgrade / removal
• PowerToys will spawn 3 error messages on logon “missing” .net Core

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.

$ winget -v 
v1.0.11451

Basically for all of the following packages upgrading is not working:

$ winget upgrade
Name                              Id                         Version      Available   Source
--------------------------------------------------------------------------------------------
Brave                             BraveSoftware.BraveBrowser 91.1.25.73   91.1.26.63  winget
Microsoft Edge                    Microsoft.Edge             91.0.864.48  91.0.864.54 winget
Mozilla Firefox                   Mozilla.Firefox            89.0         89.0.1      winget
Python 3                          Python.Python.3            2.7.150      3.9.5150.0  winget
Python 3                          Python.Python.3            3.4.4150     3.9.5150.0  winget
Microsoft Windows Desktop Runtime Microsoft.dotnetRuntime    3.1.13.29816 5.0.7.30113 winget

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 report upgrade 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:

# m4chei WORKSTATION C:\Windows\System32 [09:36:06]
❯ winget upgrade
Name                 Id                Version Available Source
---------------------------------------------------------------
Mozilla Firefox      Mozilla.Firefox   88.0.1  89.0      winget
Oracle VM VirtualBox Oracle.VirtualBox 6.1.16  6.1.22    winget

# m4chei WORKSTATION C:\Windows\System32 [09:36:19]
❯ winget upgrade --all
No applicable update found.

# m4chei WORKSTATION C:\Windows\System32 [09:36:41]
❯ winget upgrade Mozilla.Firefox
No applicable update found.

# m4chei WORKSTATION C:\Windows\System32 [09:37:13]
❯ winget upgrade Oracle.VirtualBox
No applicable update found.

@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)