winget-cli: Search and Install do not return the same results

Brief description of your issue

Steps to reproduce

run winget search wireshark run winget install wireshark

Expected behavior

If only one package is returned from search, only one package should be returned for install. Search and install should return the same available packages

Actual behavior

PS C:\WINDOWS\system32> winget search wireshark
Name      Id                            Version Source
-------------------------------------------------------
Wireshark WiresharkFoundation.Wireshark 3.4.8.0 winget
PS C:\WINDOWS\system32> winget install wireshark
Multiple packages found matching input criteria. Please refine the input.
Name                  Id                            Source
-----------------------------------------------------------
Computer Networks One 9NC6N8L4T5WS                  msstore
Wireshark             WiresharkFoundation.Wireshark winget

Environment

PS C:\WINDOWS\system32> winget --info
Windows Package Manager v1.1.12653
Copyright (c) Microsoft Corporation. All rights reserved.

Windows: Windows.Desktop v10.0.19043.1237
Package: Microsoft.DesktopAppInstaller v1.16.12653.0

About this issue

  • Original URL
  • State: closed
  • Created 3 years ago
  • Reactions: 3
  • Comments: 29 (17 by maintainers)

Commits related to this issue

Most upvoted comments

Fortunately, this is a back-end change and doesn’t require client changes. I thought I’d share this bit of information.

I don’t know why, but this one cracked me up:

PS C:\Users\easton> winget install office
Multiple packages found matching input criteria. Please refine the input.
Name                                                   Id               Source
-------------------------------------------------------------------------------
Neat Office - Word, Excel, PDF, Powerpoint alternative 9P2HTZQ722V3     msstore
Microsoft 365 Apps for enterprise                      Microsoft.Office winget

“Hi! I’m a Microsoft utility! You want Office? Have you tried ‘not Office’?”

This didn’t make the 10/18 target date. I’m chasing the next date down.

Quick update. We’re going to test some of the changes this week and anticipate a release as early as October 18th (+ or - a day depending on geography).

If this is causing too many issues for you run winget source remove msstore to use the community repo only. If you want to try it again, run winget source reset.

Here’s some more info: https://github.com/microsoft/winget-cli/discussions/1515#discussioncomment-1398086

msstore is definitely causing issues here - you don’t even get the same (incorrect) results between runs

C:\Users\peter>winget install Microsoft.VisualStudioCode
Multiple packages found matching input criteria. Please refine the input.
Name                         Id                         Source
---------------------------------------------------------------
Microsoft Whiteboard         9MSPC6MP8FM4               msstore
Microsoft Visual Studio Code Microsoft.VisualStudioCode winget

C:\Users\peter>winget install "Microsoft.VisualStudioCode"
Multiple packages found matching input criteria. Please refine the input.
Name                               Id                         Source
---------------------------------------------------------------------
Microsoft Wireless Display Adapter 9WZDNCRFJBB1               msstore
Microsoft Visual Studio Code       Microsoft.VisualStudioCode winget

The store source is approximating the REST API calls. We’ve got another change to hopefully bring the results of search and install to a more consistent state.

winget install GOG.Galaxy -s winget is a workaround also.

I ran into similar issue trying to install MS Teams: image

❯ winget --version
v1.1.12653

I know this may not be the place to ask this, but is there a way to remove msstore as a source?

I found the answer to my question. You can remove the msstore source and avoid these issues. Open elevated shell and run winget source remove msstore

I was just informed the deployment has completed.

This change is starting to roll out. It’s likely to take a day to completely roll out globally.

Thanks for bumping. We’re testing in PPE currently, and this will have a staged roll out based on geography. The roll out is scheduled to start on 10/28.

It looks like 10/25 is the next release window we’re targeting.

We’re aware of what is causing this issue. We have changes planned early next week to improve this.

I feel like there should be a “default” store that is given precedence

If the install request does not match a defined moniker, then it should attempt to match by product id (this will give precedence to the winget repository, because msstore product IDs are random strings of letters).

I’d go one step further to say that the “default” repository should be user-selectable, and that an exact-match of product id should always work if it’s unique, or if it’s available in the default repository.

If I’m adding custom/additional repositories, I don’t expect them to interfere with my “default” behavior.

I actually think “search” and “install” should not return the same results. winget search should be a wide-ranging search that matches anything in product ID, moniker or package name. winget install should give precedence to any moniker that has been defined (and monikers should be unique). If the install request does not match a defined moniker, then it should attempt to match by product id (this will give precedence to the winget repository, because msstore product IDs are random strings of letters).

On the other hand, winget install and winget show should return the same results, in my opinion. If I type winget show kiwix, I expect it to show details of the package that will install if I then type winget install kiwix. Unfortunately these commands are currently broken if a moniker is defined: see #1568.

I’ve covered a few tips in the blog for Windows Package Manager 1.1.

@Masamune3210 The ID could be case-sensitive. You wrote gog.galaxy whereas the ID is GOG.Galaxy. At least check if that might be an issue.

Definitely running into this, even specifying the id doesn’t disambiguate it enough

image