Upgrade doesn't work for several packages #752
Comments
ghost
added
the
denelon
added
Issue-Bug
|
Is upgrade work for other apps? I have the same problem with powertoys and other apps. |
Then please provide examples so that the devs can check if the issues you're describing and the PowerToys issue are identical. |
|
Powertoys - the same as author of this issue. PythonSoftwareFoundation.Python from msstore - No applicable update found. Full log |
|
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. |
|
Thanks for the additional data points here. Some applications work "Microsoft.WindowsTerminalPreview" and "Microsoft.WindowsTerminal" while others don't. |
|
so, only msix? |
|
Not sure if this issue is related but when running winget list I do not see a source for all my apps I have installed with winget. The ones I see with a source in winget list I can upgrade. |
|
On a similar note, PowerShell cannot be upgraded either (shipped as a MSI, product code in manifest). |
|
Any update yet? I saw new release but not mentioning this issue. |
denelon
changed the title
|
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. |
|
Another data point: with the most recent version of winget, GitHub CLI (shipped as an MSI) can't be upgraded: But if you run Does upgrade run the installers with different command line arguments than install? |
|
Edit: Please disregard this comment for the issue at hand. Another reproduction. WinGet-2021--4--9-22-36-21.337.log |
|
Still showing no upgrade for vscode, git, python, cmake, MPC-HC, qbittorrent. |
|
Additional examples, both from microsoft:
|
|
You don't happen to still have the logs from those. do you? I'm curious about where it is failing. |
|
We're starting to work through some of the end to end upgrade scenarios. If you know of any other specific packages that don't seem to upgrade correctly, let us know the package identifiers so we can dig in. |
|
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. |
|
This issue was created as a placeholder to track the more generic 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. In others, it's related to the scope of the installed program and the scope the user is in. Still others are related to nested installers. 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. |
|
I can confirm there are major improvements to the behaviour. Thanks for the persistence and solving them. |
|
Even some Microsoft packages still seem to have problems of this type. Using WinGet v1.3.1872: Does this particular package require some kind of enterprise admin permissions I don't have? |
|
No, that's clearly a "hash mismatch". That means the installer file changed at the URL "https://officecdn.microsoft.com/pr/wsus/setup.exe". We have automation that will check daily and if a mismatch is detected, we will update the hash after validating the package. |
|
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 The installation reports success, but subsequent checks don't seem to verify that. Others have reported similar issues. If I do I can download |
|
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
|
|
Hi! one thing to note - I have chocolatey and originally this app was installed with |
WinGet uses the information reported by the Control Panel instead of Chocolatey which reports the latest version it installed. So in theory this is just a Microsoft issue.. |
|
Add to the list: |
|
Make a issue at https://github.com/microsoft/winget-pkgs/issues. |
The funny thing is that WinGet is also a Microsoft project. Are there any workarounds to force WinGet to ignore that package? Now |
WinGet is a highly community run project, Microsoft Office is a proprietary software. |
|
I had this problem when two versions of the same application was installed,
one per machine and one per user.
I removed one of them and this solved the problem.
|
|
Same issue. |
|
This is a serious issue. We need a way to exclude the packages or fix this. Keeps installing these 2 over and over.
|
|
Surp
This fixed it, removing the wide machine installer fixed it. But surprised it's still happening |
|
Still getting this problem with ... |
and others
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.
The text was updated successfully, but these errors were encountered: