Closed AdilHindistan closed 4 years ago
I have the same issue trying to Install FireFox.
It seems that if there is an exact match, then that should be installed.
I was able to install or upgrade PowerShell using the exact match parameter
winget install -e Microsoft.Powershell
A better solution to installing PowerShell7 is to use the install-powershell command in power shell's github repo. It gives you much more flexibility. It can also be remoted over PS Remoting, which winget appears to not handle.
A better solution to installing PowerShell7 is to use the install-powershell command in power shell's github repo. It gives you much more flexibility. It can also be remoted over PS Remoting, which winget appears to not handle.
Good point but I believed winget was designed in similar functionality to apt utility, meaning you have to be on the server/machine in some form to use it. I guess you can use PS and winget together to extend that functionality...my 2c
I ran into the same problem today. I would expect it to be interactive like:
"Multiple packages matched your query. Please select one of the following: [1] Microsoft.Powershell [2] Microsoft.PowerShell-Preview"
Anyway thanks for the awesome work 💪
This worked fine about 2 days ago, but the 7.1.0 preview version was not available at that time. Unfortunately, I am not having any success using the '-e' switch either. :(
Ran into this same issue as well.
winget install -e Microsoft.Powershell
did work for me but these circumstances should probably be handled a bit cleaner with perhaps a selection list or some other method.
Thanks for the great work on this!
I ran into the same problem today. I would expect it to be interactive like:
"Multiple packages matched your query. Please select one of the following: [1] Microsoft.Powershell [2] Microsoft.PowerShell-Preview"
Anyway thanks for the awesome work
The problem is, preview version should not even come up when the version is specified. Names are similar but versions are different. It's as if version is totally ignored.
winget install -e Microsoft.PowerShell
doesn't work.
winget install -e Microsoft.Powershell
does work.
The search is case sensitive! (https://github.com/microsoft/winget-pkgs/pull/884)
How would I discover -e. And what does '-e' mean? A bad UI.
@doctordns winget install --info
--info doesn't exist on install but it will return the options.
First thing i tried was winget install
hoping that it would return the help of the install module.
winget team -> Loving this cli so far by the way! 👍
I had a similar problem trying to install Discord
PS C:\Users\orta> winget
Windows Package Manager v0.1.41331 Preview
Copyright (c) Microsoft Corporation. All rights reserved.
WinGet command line utility enables installing applications from the command line.
usage: winget [<command>] [<options>]
The following commands are available:
install Installs the given application
show Shows info about an application
search Find and show basic info of apps
hash Helper to hash installer files
validate Validates a manifest file
For more details on a specific command, pass it the help argument. [-?]
The following options are available:
-v,--version Display the version of the tool
--info Display general info of the tool
More help can be found at: https://aka.ms/winget-command-help
PS C:\Users\orta> winget install discord
Multiple apps found matching input criteria. Please refine the input.
Name Id Version
--------------------------------------------
Discord Discord.Discord 0.0.306
Discord Canary Discord.DiscordCanary 0.0.264
PS C:\Users\orta> winget install discord.discord
Multiple apps found matching input criteria. Please refine the input.
Name Id Version
--------------------------------------------
Discord Discord.Discord 0.0.306
Discord Canary Discord.DiscordCanary 0.0.264
PS C:\Users\orta> winget install Discord.Discord
Multiple apps found matching input criteria. Please refine the input.
--------------------------------------------
Discord Discord.Discord 0.0.306
Discord Canary Discord.DiscordCanary 0.0.264
PS C:\Users\orta> winget install --help
Windows Package Manager v0.1.41331 Preview
Copyright (c) Microsoft Corporation. All rights reserved.
Installs the given application
usage: winget install [[-q] <query>] [<options>]
The following arguments are available:
-q,--query The query used to search for an app
The following options are available:
-m,--manifest The path to the manifest of the application
--id Filter results by id
--name Filter results by name
--moniker Filter results by app moniker
-v,--version Use the specified version; default is the latest version
-s,--source Find app using the specified source
-e,--exact Find app using exact match
-i,--interactive Request interactive installation; user input may be needed
-h,--silent Request silent installation
-o,--log Log location (if supported)
--override Override arguments to be passed on to the installer
-l,--location Location to install to (if supported)
More help can be found at: https://aka.ms/winget-command-install
PS C:\Users\orta> winget install --id Discord.Discord
Multiple apps found matching input criteria. Please refine the input.
Name Id Version
--------------------------------------------
Discord Discord.Discord 0.0.306
Discord Canary Discord.DiscordCanary 0.0.264
( and I kinda left it at that and installed it manually )
@orta it would probably work if you used
winget install --exact Discord.Discord
or winget install -e Discord.Discord
problem is that: 1) -e option is not obvious 2) It's Case sensitive, and that's not obvious either both of these are documentation problems. If winget team took a clue from PowerShell team and actually created a help that's useful, with examples, people could have discovered how to do these.
There are other problems though, mainly disregard for version. I cannot think of any good reason why this should not work:
winget install --id Discord.Discord --version 0.0.306
that's nuts!
My takeaway here is the semantic text being used here. Right now winget install
behaves exactly like winget show
at times where it can't find an exact output.
install
is a command, the verb is specific in nature and implicitly suggests that it expects an exact match. The install command should fail
when a exact match cannot be picked out (with appropriate messaging).
How does Winget KNOW that I do not want both versions loaded? I have two versions of Snagit, Multiple versions of.NET, etc. And if 'install' is a verb, then 'show' should be 'get'. From my phone so apologies for the typos. !
BTW
winget install -e Microsoft.Powershell
will install 7.0.0
to install the latest run
winget install --id Microsoft.PowerShell -e
This worked for me, but others have reported that it didn't work (I see a PR has been made to make this work):
winget install -e Microsoft.PowerShell
This worked for me, but others have reported that it didn't work (I see a PR has been made to make this work):
winget install -e Microsoft.PowerShell
I had that issue and winget install Microsoft.PowerShell -e
worked like a charm
same issue with me but installing git through winget
I ran into this issue specifically with terminal; I saw on one of the blogs about winget suggesting i could simply "winget install terminal" and I was very excited to try this 😅
I think one solution (to these specific packages) is to exclude preview/prerelease packages unless a flag is provided. Notify that prereleases are available if you insist, but unless a user is explicitly trying to install a prerelease, listing it in the default query may not be helpful.
Although hiding the preview is a solution for now, if someone comes along with SuperTerminal or TerminalX, users will have the exact same issue again, needing to qualify "Microsoft.WindowsTerminal" (it's a lot to type, relative to other package managers, terminal
is a lot more concise and memorable!). I imagine some kind of name aliasing for packages or prompting the user to ask about a best match (unless it's run non-interactively) would be better long term solutions.
At the moment, when installing apps with multiple search results, the following nomenclature is working perfectly:
winget install --name <appName> -e
Note that the appName is Case Sensitive !
@SubhamK108 Thanks for the short solution.
I was able to install or upgrade PowerShell using the exact match parameter
winget install -e Microsoft.Powershell
This also worked for me, although I did get an error with Google Chrome about the "installer hash verification failed." Everything else worked great.
I was able to install or upgrade PowerShell using the exact match parameter
winget install -e Microsoft.Powershell
The documentation/help is not clear about -e which is too bad and easy to fix
winget install -e Microsoft.PowerShell
doesn't work.
winget install -e Microsoft.Powershell
does work.The search is case sensitive! (microsoft/winget-pkgs#884)
However, now things have changed:
winget install -e Microsoft.PowerShell
does work while winget install -e Microsoft.Powershell
doesn't work.
@Sciroccogti The same for me. However at the end of installation I received a message "Installation abandoned". Nevertheless the installation completed successfully.
@Sciroccogti The same for me. However at the end of installation I received a message "Installation abandoned". Nevertheless the installation completed successfully.
Oh yes I received that message as well, but I was running the powershell installation in powershell itself, so I think it's normal for it to be 'abandoned'.
Same issue trying to install Terminal as others have stated:
winget install Microsoft.WindowsTerminal
Fails with:
Multiple apps found matching input criteria. Please refine the input.
Name Id Version
--------------------------------------------------------------------
Windows Terminal Microsoft.WindowsTerminal 1.0.1401.0
Windows Terminal Preview Microsoft.WindowsTerminalPreview 1.1.1671.0
Workaround confirmed working using the -e:
winget install -e Microsoft.WindowsTerminal
Using this as install button is broken in Microsoft Store again and re-registering app-x packages is failing this time.
winget install --id<appID> -e
Like the others, I'm having the same sort of issue
winget install Google.Chrome
outputs this
Multiple apps found matching input criteria. Please refine the input.
Name Id Version
------------------------------------------
Chrome Google.Chrome 84.0.4147.89
Chrome Beta Google.ChromeBeta 84.0.4147.38
Only was able to work with the -e flag
winget install -e Google.Chrome
If package IDs were unique, shouldn't the install command default to ID for seamless usage?
There were a few steps involved in getting a solution to this Issue. We are using some of the same codebase on the server to build the database of apps. The issue is that a substring wasn't being treated as an "exact" match for show or install. We're testing a version of the client that will hopefully provide a resolution.
Also in the screenshot above is it a bit strange that Chrome Beta is actually an older version than Chrome non-beta. Does this mean repos are not yet kept up to date?
@AdilHindistan this Issue should be resolved with the current release of the client (v0.1.42101 Preview). The matching criteria for show
and install
are identical and will lock on an "exact" string match. The matching criteria for search is still more broad to help locate packages with matching substrings.
I have a similar issue trying to upgrade Plexamp. I'm not sure why but it detects multiple instances on my system.
Multiple installed packages found matching input criteria. Please refine the input.
Name Id
----------------------------------------------------
Plexamp Plex.Plexamp
Plexamp 3.4.4 {46418f0f-cea3-5740-a7e9-a0166db1e7c4}
You'd think winget upgrade Plex.Plexamp -e
or winget upgrade -e Plex.Plexamp
(both similar to suggestions listed above) would work, but they don't. Neither do winget upgrade --id Plex.Plexamp -e
nor winget upgrade --name Plexamp -e
. Driving me crazy honestly.
@pressRtowin what is the output for winget list plexamp
and winget upgrade
?
@denelon
Name Id Version Available Source
---------------------------------------------
Plexamp Plex.Plexamp 3.4.6
Plexamp Plex.Plexamp 3.4.4 3.4.6 winget
The second line is from running winget install --id Plex.Plexamp -e
just today which worked, unlike upgrade
. winget upgrade
only shows Plexamp Plex.Plexamp 3.4.4 3.4.6 winget
now since running that, but before it showed something similar (without winget as the source). It never displayed the {windowsappIDnonsense} version in the upgrade list.
Is it working correctly now?
I've run into cases where a package installed two instances in Add/Remove Programs. The Cura program is an .exe installer that doesn't "upgrade" it just installs the new version beside the old one. I had 4.8.0 on my machine, and I ran winget upgrade
. It then installed the 4.9.1 version, and now when I run winget list cura
you see the old one looks like an upgrade is available, and the new one is current.
winget list cura
Name Id Version Available Source
------------------------------------------------------
Ultimaker Cura Ultimaker.Cura 4.8.0 4.9.1 winget
Ultimaker Cura Ultimaker.Cura 4.9.1
Nothing has changed.
@pressRtowin I just tested:
PS C:\Users\denelon> winget search PowerShell
Name Id Version Match Source
----------------------------------------------------------------------------------------------------
PowerShell Microsoft.PowerShell 7.1.3 winget
Windows Terminal Preview Microsoft.WindowsTerminalPreview 1.9.1445.0 Tag: PowerShell winget
Windows Terminal Microsoft.WindowsTerminal 1.8.1444.0 Tag: powershell winget
PowerShell-Preview Microsoft.PowerShell-Preview 7.2.0-preview.6 Tag: powershell winget
EasyConnect lstratman.easyconnect 3.1.0.105 Tag: powershell winget
Oh My Posh JanDeDobbeleer.OhMyPosh 3.160.1 Tag: PowerShell winget
PowerShell Preview (MSIX) Microsoft.PowerShell-Preview-MSIX 7.0.2 winget
PowerShell Universal IronmanSoftware.PowerShellUniversal 1.4.0 winget
PS C:\Users\denelon> winget install PowerShell
Found PowerShell [Microsoft.PowerShell]
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/PowerShell/PowerShell/releases/download/v7.1.3/PowerShell-7.1.3-win-x64.msi
██████████████████████████████ 95.0 MB / 95.0 MB
Successfully verified installer hash
Starting package install...
Successfully installed
PS C:\Users\denelon>
What version of the Windows Package Manager are you running?
Windows Package Manager v1.0.11451
@pressRtowin can you share output like I did from the same two commands? I'd like to see what might be different.
I have no issues installing powershell...
@pressRtowin it looks like two instances of Plexamp were installed on your system. That's the same as the "Cura" example I have above. I don't know if the Plexamp installer actually recognizes the earlier version and upgrades it or if it is designed to support "side by side" installation. Some packages are designed with this intentional behaviors. For packages that aren't, you might need to have the manifest modified for the "UpgradeBehavior" to specify uninstall to remove the "older" version before installing the "newer" version.
@denelon Doesn't really explain why winget is giving a "Please refine the input." error and not some type of installation error, especially when I'm specifying an exact match using the ID fields which are clearly different in the two matches that it finds. The duplicate IDs in winget list plexamp
would've only been a thing after I ran the install command but I was having the same error before that.
Generally, the "Please refine the input" error happens when the client needs the user to disambiguate between multiple options. This happens several places in the code. If the -id is not distinctly identifying the package manifest or a "single" entry in "Add / Remove Programs" this happens. I believe what is happening is either the two entries in "Add / Remove Programs" aren't unique enough (I think there is work here in the client), or for some reason more than one manifest matched some set of criteria. This may be similar to https://github.com/microsoft/winget-pkgs/discussions/16038
@pressRtowin can you re-create the conditions in a virtual machine and share the logs? You may very well have encountered a bug, or something changed with the manifests, and the problem was corrected. I would be more than happy to take a look at how we could fix the problem if this is a reproduceable bug.
Getting a similar situation trying to upgrade the .NET 5.0 SDK. Because I also have the 6.0 preview, it picks that up too, and returns "refine the input" even if I specify the ID of the 5.0 package:
Microsoft .NET SDK Microsoft.dotnet Microsoft .NET SDK 6.0.100-preview.4.21255.9 (x64) {e0100246-937c-4ed6-b71f-2e37cf75fe43}`
This issue still exists:
TeamViewer TeamViewer.TeamViewer 15.21.5 15.21.6 winget TeraCopy CodeSector.TeraCopy 3.8.2 3.8.5 winget Plexamp plex.Plexamp 3.4.0 3.5.0 winget Python 3 Python.Python.3 3.9.5150.0 3.9.6150.0 winget
TeraCopy CodeSector.TeraCopy TeraCopy version 3.8.2 TeraCopy_is1
Python 3 Python.Python.3 Python 3.9.5 (32-bit) {708847ae-c2de-49fb-9b85-8d2e9c991358}
Plexamp plex.Plexamp Plexamp 3.4.0 {46418f0f-cea3-5740-a7e9-a0166db1e7c4}
Any news on this - it's rendering winget basically unusable for alot of packages, in part because "exact" doesn't seem to mean exact at all. For example:
Microsoft Visual C++ 2013 Redistributable (x86) Microsoft.VC++2013Redist-x86 Microsoft Visual C++ 2013 Redistributable (x64) - 12.0.40664 {042d26ef-3dbe-4c25-95d3-4c1b11b235a7}
I've include "x86" in my name parameter, so why is it "exactly" matching the x64 version?
Brief description of your issue
When I try to install PowerShell 7.0.1, winget cannot seem to locate the correct one
Steps to reproduce
None of these work winget install PowerShell winget install Powershell winget install Microsoft.Powershell winget install --id Microsoft.Powershell --version 7.0.1
Expected behavior
It should pick up Powershell 7.0.1 (btw, that should have been named PowerShell not Powershell)
Actual behavior
I get the following:
Environment