`winget upgrade --id XP89DCGQ3K6VLD --version 0.81.1` fails even if `winget upgrade` says that version is available

sba923 commented 4 weeks ago

Brief description of your issue

On a system where winget upgrade reports that version 0.81.1 of PowerToys is available, winget upgrade --id XP89DCGQ3K6VLD --version 0.81.1 fails with No version found matching: 0.81.1

Steps to reproduce

Run winget upgrade --id XP89DCGQ3K6VLD --version 0.81.1 on a system with PowerToys 0.81.0 installed

Expected behavior

PowerToys should be upgraded to 0.81.1

Actual behavior

Environment

Windows Package Manager v1.7.11261
Copyright (c) Microsoft Corporation. All rights reserved.

Windows: Windows.Desktop v10.0.22621.3593
System Architecture: X64
Package: Microsoft.DesktopAppInstaller v1.22.11261.0

Winget Directories                 
-----------------------------------------------------------------------------------------------------------------------
Logs                               %LOCALAPPDATA%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\DiagΓÇª
User Settings                      %LOCALAPPDATA%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\settΓÇª
Portable Links Directory (User)    %LOCALAPPDATA%\Microsoft\WinGet\Links
Portable Links Directory (Machine) C:\Program Files\WinGet\Links
Portable Package Root (User)       %LOCALAPPDATA%\Microsoft\WinGet\Packages
Portable Package Root              C:\Program Files\WinGet\Packages
Portable Package Root (x86)        C:\Program Files (x86)\WinGet\Packages
Installer Downloads                %USERPROFILE%\Downloads

Links               
---------------------------------------------------------------------------
Privacy Statement   https://aka.ms/winget-privacy
License Agreement   https://aka.ms/winget-license
Third Party Notices https://aka.ms/winget-3rdPartyNotice
Homepage            https://aka.ms/winget
Windows Store Terms https://www.microsoft.com/en-us/storedocs/terms-of-sale

Admin Setting                             State
--------------------------------------------------
LocalManifestFiles                        Disabled
BypassCertificatePinningForMicrosoftStore Disabled
InstallerHashOverride                     Disabled
LocalArchiveMalwareScanOverride           Disabled

github-actions[bot] commented 4 weeks ago

Hi I'm an AI powered bot that finds similar issues based off the issue title.

Please view the issues below to see if they solve your problem, and if the issue describes your problem please consider closing this one and thumbs upping the other issue to help us prioritize it. Thank you!

Open similar issues:

Latest version not working (#3806), similarity score: 0.75

Closed similar issues:

Upgrade Microsoft.PowerToys is not working (#1801), similarity score: 0.78
Upgrade doesn't work for several packages (#752), similarity score: 0.75

Note: You can give me feedback by thumbs upping or thumbs downing this comment.

Trenly commented 4 weeks ago

Does it work if you just run winget upgrade --id XP8DCGQ3K6VLD ?

denelon commented 4 weeks ago

This is an interesting looking edge case where at least at one point, it appears PowerToys had been installed using the Microsoft Store, and at another point, WinGet acted on the package using the "winget" source. I don't think I've seen this before. I'll have to see if there is a way I can reproduce this scenario, but my guess is it will have to wait until a newer version of PowerToys comes out and is published to the "winget" source after installing an earlier version from the "msstore" source.

I don't believe the upgrade command will do anything using the ID from the "msstore" source since that source doesn't provide a version for WinGet to reason about an upgrade being available. That's also why the "no match" error is being reported.

I'd say the "msstore" source is acting as expected (not necessarily what I'd want it to do) giving no version information to WinGet, so WinGet is also acting as expected giving the error message. The real issue in my mind is how the device got into that state, and how WinGet can do the right thing in the future given this scenario.

Nice find @sba923!

denelon commented 4 weeks ago

Get ready for a terrible run on sentence:

My best guess at clearing the issue up is to perform an uninstall using the store Id, and then a reinstall using the "winget" source since no automatic updates are afforded for Win32 packages coming from the "msstore" source, and no version information is coming from the "msstore" source via the endpoint used by WinGet to test using version logic for a newer version.

sba923 commented 4 weeks ago

No problem with the long sentence 😆

I had something like that in mind.

I actually ended up using PowerToys' self-update mechanism.

I can't even remember why the msstore source had been used on that machine.

The fact that I'm using a msstore application ID in conjunction with a version number is due to my workaround to https://github.com/microsoft/winget-cli/issues/4283: I'm enumerating the available updates using Get-WinGetPackage and then perform the updates in a loop with winget upgrade --id XXX --version YYY.

sba923 commented 4 weeks ago

Does it work if you just run winget upgrade --id XP8DCGQ3K6VLD ?

sorry, can't test anymore as I have performed the upgrade another way 😢

sba923 commented 3 weeks ago

This is an interesting looking edge case where at least at one point, it appears PowerToys had been installed using the Microsoft Store, and at another point, WinGet acted on the package using the "winget" source. I don't think I've seen this before. I'll have to see if there is a way I can reproduce this scenario, but my guess is it will have to wait until a newer version of PowerToys comes out and is published to the "winget" source after installing an earlier version from the "msstore" source.

I don't believe the upgrade command will do anything using the ID from the "msstore" source since that source doesn't provide a version for WinGet to reason about an upgrade being available. That's also why the "no match" error is being reported.

I'd say the "msstore" source is acting as expected (not necessarily what I'd want it to do) giving no version information to WinGet, so WinGet is also acting as expected giving the error message. The real issue in my mind is how the device got into that state, and how WinGet can do the right thing in the future given this scenario.

Nice find @sba923!

You're welcome!

Based on your clarification, I'm removing the --version argument when my Update-AllAppsWithWinGet.ps1 script processes packages from the msstore source.

microsoft / winget-cli