`upgrade` and `uninstall` commands default to using msstore instead of respecting the package source that the package was originally installed from

[rxlecky]

Brief description of your issue

When upgrade and uninstall commands are used with parameter which ambiguously matches the package from both winget and msstore package sources, msstore takes precedence, even if the package was installed from winget source.

Steps to reproduce

Upgrade command

The following winget commands can be used to reproduce the issue with upgrade command.

1. winget install todoist -v 8.12.1 -s winget --accept-package-agreements --accept-source-agreements

After this command completes, running winget list todoist shows us that the package was installed with correct version, using the correct package source and that an upgrade is available:

Name           Id            Version Available Source
-----------------------------------------------------
Todoist 8.12.1 Doist.Todoist 8.12.1  9.1.1     winget

2. winget upgrade todoist --accept-package-agreements --accept-source-agreements

After upgrading, running winget list todoist again reveals multiple issues:

Name           Id             Version Available Source
------------------------------------------------------
Todoist 8.18.0 XP99K37G9CWBDC 8.18.0  9.1.1     winget

Firstly, the package ID changed, indicating that something went wrong. We can search for this package using winget search -e XP99K37G9CWBDC which reveals that this package is actually hosted on msstore package source:

Name                          Id             Version Source
-------------------------------------------------------------
Todoist: To-Do List & Planner XP99K37G9CWBDC Unknown msstore

So our package has upgraded from msstore, instead of using winget package source that the package was originally installed from.

Secondly, the package is listed as using winget source, despite it actually coming from msstore as we just confirmed.

And thirdly, the package was not upgraded to the latest version. Originally, winget list/upgrade showed that version 9.1.1. is available, but we instead got upgraded to 8.18.0. Upgrade to 9.1.1. is still available after the upgrade. Running winget show -e XP99K37G9CWBDC reveals why the upgrade to this seemingly random version was made:

Found Todoist: To-Do List & Planner [XP99K37G9CWBDC]
Version: 8.18.0
Publisher: Doist Inc.
Publisher Url: https://todoist.com/
Publisher Support Url: https://todoist.com/help
Description: ...

Version 8.18.0 is simply the latest version of the package available on msstore package source, and the more recent 9.1.1 is only available via winget source. So not only did the package change the package source without us noticing, but it also ended up not fully upgraded to latest version because of it.

Now to remedy the situaton and to complete the upgrade, we can try re-running the previous command, winget upgrade todoist --accept-package-agreements --accept-source-agreements, but we actually get an error stating the following:

No available upgrade found.
No newer package versions are available from the configured sources.

This is despite winget list/upgrade telling us that upgrade to version 9.1.1. is available. To actually finalize the upgrade, we need to either specify the package source or use the winget-source-appropriate package ID, using the following commands:

winget upgrade todoist -s winget --accept-package-agreements --accept-source-agreements
or
winget upgrade Doist.Todoist --accept-package-agreements --accept-source-agreements

Uninstall command

Furthemore, this issue also affects the uninstall command. After installing the package from winget package source, uninstalling it with the following command winget uninstall todoist --accept-source-agreements results in an output indicating that it uninstalled the msstore version of the package - even though we haven't installed it from msstore:

Found Todoist: To-Do List & Planner [XP99K37G9CWBDC]
Starting package uninstall...
Successfully uninstalled

Afterwards, attempting to install the package from winget package source results in an installation error.

However, if we specify the package source in the uninstall command winget uninstall todoist -s winget --accept-source-agreements, it correctly uninstalls the winget version of the package and it is possible to reinstall the package without errors. We can tell the uninstall used the correct version by the reported package name and ID, compared to the above:

Found Todoist [Doist.Todoist]
Starting package uninstall...
Successfully uninstalled

Expected behavior

Upgrade command

The package should upgrade using the source it was originally installed from and, unless specified otherwise, upgrade to the latest version.

If the requested version of the package is only available from a different source we should consider upgrading from a different package store. But even in such case, it would be better to fail the upgrade operation, inform the user about this issue and let them decide whether they want to switch package source. Then they can rerun the command with either --force or --allow-different-source to continue the upgrade from a different source.

Uninstall command

The package source that the package was installed from should always be used.

Actual behavior

The upgrade and the uninstall commands both default to using the msstore source, instead of respecting the source that the package was originally installed from.

Environment

Windows Package Manager v1.6.3482
Windows: Windows.Desktop v10.0.22621.3296
Package: Microsoft.DesktopAppInstaller v1.21.3482.0

[github-actions]

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!

Closed similar issues:

• Installed an app from Windows Store (source) but Winget Upgrade command downloads the update from Winget (source: Github) (#643), similarity score: 0.78

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

[rxlecky]

This indeed appears like a duplicate of #643. However, the original issue was posted in 2020, back when the upgrade command was a WIP feature and local tracking of the package source was not yet implemented. However, I assume this feature has since been implemented since we get a package source displayed when using list and upgrade commands. From my limited testing, this also works offline so it's not looking up the package sources online either.

So, the cause for this issue may well still be the same as it was back when #643 was reported, however, I believe that since then the limitations that prevented this feature from being implemented have been resolved. Moreover, the fact that this bug also affects the uninstall command, resulting in incomplete uninstallation and possible corruption of installation directories warrants attention, in my opinion.

[denelon]

Yeah, we've still got some work to do on the matching logic, and we're hoping to get version information from the "msstore" source so we can correlate properly.

[github-actions]

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!

Closed similar issues:

• Installed an app from Windows Store (source) but Winget Upgrade command downloads the update from Winget (source: Github) (#643), similarity score: 0.78

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

[rxlecky]

This indeed appears like a duplicate of #643. However, the original issue was posted in 2020, back when the upgrade command was a WIP feature and local tracking of the package source was not yet implemented. However, I assume this feature has since been implemented since we get a package source displayed when using list and upgrade commands. From my limited testing, this also works offline so it's not looking up the package sources online either.

So, the cause for this issue may well still be the same as it was back when #643 was reported, however, I believe that since then the limitations that prevented this feature from being implemented have been resolved. Moreover, the fact that this bug also affects the uninstall command, resulting in incomplete uninstallation and possible corruption of installation directories warrants attention, in my opinion.

[denelon]

Yeah, we've still got some work to do on the matching logic, and we're hoping to get version information from the "msstore" source so we can correlate properly.