winget-cli
winget-cli copied to clipboard
microsoft
"No installed package found matching input criteria." when attempting to update
Brief description of your issue
when i run winget upgrade, several programs have updates. for some, such as mozilla thunderbird, attempting to run the update causes a "No installed package found matching input criteria." error.
if i uninstall the program and reinstall using winget, it works find however.
example command: winget upgrade Mozilla.Thunderbird
Steps to reproduce
use command winget upgrade Mozilla.Thunderbird on version 102.4.1. it might appear.
Expected behavior
winget begins to upgrade the application
Actual behavior
winget throws a error "No installed package found matching input criteria."
Environment
Windows Package Manager v1.3.2691
Copyright (c) Microsoft Corporation. All rights reserved.
Windows: Windows.Desktop v10.0.19045.2251
System Architecture: X64
Package: Microsoft.DesktopAppInstaller v1.18.2691.0
Logs: %LOCALAPPDATA%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\DiagOutputDir
current affected programs:
Mozilla Thunderbird
(Mozilla.Thunderbird)
Same issue here.
Location: UK
perhaps this is a issue with something in the UK, does winget use region specific servers or something like that?
additionally, i have attached a screenshot, in case this helps.
Same issue here in Germany since more than a week i think.
(basically the same just with German language)
since i am in Germany it is probably not an issue regarding something in the UK
Yeah, I don't think it is country-specific - I'm in NYC and it's completely broken here too:
Not only that, but it also mis-detects the version to be 7.2.5.0 when I actually have 7.3.0 installed for some time now...
having that problem for a long time. winget upgrade lists a package. but then it doesnt upgarde, neiter by using --all nor by using any variant of its name. after a couple of days it usually works.
PS C:\Users\Michael> winget upgrade
Name ID Version Verfügbar Quelle
------------------------------------------------------------------------------
LibreOffice 7.4.2.1 TheDocumentFoundation.LibreOffice 7.4.2.1 7.4.2.3 winget
1 Aktualisierungen verfügbar.
1 Paket hat eine Versionsnummer, die nicht bestimmt werden kann. Wenn Sie „--include-unknown“ verwenden, werden möglicherweise weitere Ergebnisse angezeigt.
PS C:\Users\Michael> winget upgrade Libreoffice
Es wurden keine anwendbaren Aktualisierungen gefunden.
PS C:\Users\Michael> winget upgrade TheDocumentFoundation.LibreOffice
Es wurden keine anwendbaren Aktualisierungen gefunden.
PS C:\Users\Michael> winget upgrade --all
Name ID Version Verfügbar Quelle
------------------------------------------------------------------------------
LibreOffice 7.4.2.1 TheDocumentFoundation.LibreOffice 7.4.2.1 7.4.2.3 winget
1 Aktualisierungen verfügbar.
1 Paket hat eine Versionsnummer, die nicht bestimmt werden kann. Wenn Sie „--include-unknown“ verwenden, werden möglicherweise weitere Ergebnisse angezeigt.
PS C:\Users\Michael>
I have same issue with a couple of packages. In the beginning I was able to solve the issue by uninstalling the package and install it again with Winget but after a couple of updates it fails again
In addition, I just discovered my PuTTY was removed - is it possible that, while failing to install the new one, winget first did successfully remove my existing version? If so, that's very much not cool...
In addition, I just discovered my PuTTY was removed - is it possible that, while failing to install the new one, winget first did successfully remove my existing version? If so, that's very much not cool...
@szlevi Please note that this was done intentionally to align with the publisher's changelog:
Note: installing the 0.78 or later Windows installer will not automatically uninstall 0.77 or earlier, due to a change we've made to work around a bug. We recommend uninstalling the old version first, if possible. If both end up installed, uninstalling both and then re-installing the new version will fix things up.
Please see https://github.com/microsoft/winget-pkgs/pull/87021
In addition, I just discovered my PuTTY was removed - is it possible that, while failing to install the new one, winget first did successfully remove my existing version? If so, that's very much not cool...
@szlevi Please note that this was done intentionally to align with the publisher's changelog:
Note: installing the 0.78 or later Windows installer will not automatically uninstall 0.77 or earlier, due to a change we've made to work around a bug. We recommend uninstalling the old version first, if possible. If both end up installed, uninstalling both and then re-installing the new version will fix things up.
Please see microsoft/winget-pkgs#87021
Ah, I see, thanks. So it's just a temp issue, right?
Ah, I see, thanks. So it's just a temp issue, right?
That depends on the publisher. If future installers perform "in-place" upgrade instead of requiring the version to be manually uninstalled first, the behavior will be duly updated in the winget's manifest.
i've found another package that has the same issue, the microsoft visual C++ redistributable 2013, specifically the x64 version has the issue, not the x86 version which updated fine. can we have a developer explain why this issue is appearing?
The matching logic is based on comparing what values are written to the registry (it's the same thing that powers what you see in Windows Apps & Features), and what metadata is listed in manifests in all configured sources. Sometimes the installer isn't reporting things consistently to the registry and in other cases, the manifest doesn't have all the variations of what is reported.
WinGet looks at package family name, product code, upgrade code, display name, and display version. Depending on what is available, heuristics are used to determine the "best match" when there isn't an exact match.
As the Visual C++ Redistributable packages can be installed side-by-side for different versions and different architectures, it's been more challenging to capture all the correct metadata for all the variations. We are incrementally making improvements with both the manifests and the client (matching logic and upgrade/install logic), but clearly there is still more work to be done.
without any known changes, libreoffice today suddenly updated just fine. 7.4.2.1 -> 7.4.2.3
Facing this very same issue while upgrading Powershell, i don't know yet if this happens only with certain packages
There are a couple of classes of issues. One is when the installer type has changed. For the most part, I think we've isolated that path and resolved it.
Another is when it's an MSI based installer and we aren't getting a good match for the "Product Code" or "Upgrade Code".
Another is when the package is installed in either "user" or "machine" scope and the upgrade is defaulting to the opposite scope, or the user has a requirement in their settings which doesn't match the installed scope or the default scope specified in the manifest.
Hi everyone, I'm from Colombia and I'm getting the same issue.
I have solved it adding flag --include-unknown
As my understanding, when the winget command try to get the apps to update, there are some packages with a "Broken" version in the repository. I don't understand the consecuences of upgrade with --include-unknown flag, but it works for me.
winget upgrade --all --include-unknown
I'm getting the same issue after successfully upgrading about 4-5 apps, then none would upgrade after that and I was met with the "no installed package found matching input criteria." message when trying to upgrade any of the 7 that remained.
I done some googling (as you do) and tried with a slightly different command syntax, instead of specifying the ID I just specified the name of the application.
So instead of winget upgrade --id VideoLAN.VLC I tried winget upgrade "VLC Media Player"
This appeared to work, at least for VLC Media Player.
I'm really not sure of the implications of doing it this way, I'm not sure if my Winget just had a temporary issue and it would have worked using the original commands eventually (as others have mentioned on google)
Exactly same behaviour for Git, specifying it by ID did not work, specifying it by the Name did work. Very odd!
I got the same issue running the winget upgrade -all command from an elevated PowerShell. But it worked when I ran it in a non-elevated cmd.exe. Real PITA having to type my admin user and password for every single update
FYI, upgrade worked here for Microsoft .NET SDK 7.0.203 (x64) (to version 7.0.401) -- by not using the app Id (in this case Microsoft.DotNet.SDK.7), but by entering the complete name between quotes.
Like so winget upgrade "Microsoft .NET SDK 7.0.203 (x64)". You may even have to do a --force.
JJ
I know it's an old thread, but I was having this issue as well. I solved it by running these two commands.
winget uninstall Microsoft.Winget.Source_8wekyb3d8bbwe winget source reset --force
I have same issue for VLC Media Player (VideoLAN.VLC) .
Same here. I got it working by doing what @jonkeren wrote in his post (https://github.com/microsoft/winget-cli/issues/2686#issuecomment-1721441017)
Use the name instead of the id.
Just to note I'm seeing the same behaviour with winget install on a clean Windows 11 (reset) build. I've got a script with a number of packages to install based on the ID and it just loops this error for all of them
Any update on this issue? Same for SSMS. And using a name instead of ID is nice as a workaround, but not as a fix :(
I know it's an old thread, but I was having this issue as well. I solved it by running these two commands.
winget uninstall Microsoft.Winget.Source_8wekyb3d8bbwe winget source reset --force
Thanks, it worked finally😱
This thing had been bugging me since 2021 with similar issues for it being present but no progress. ✔
One thing is that the winget source reset --force needs to run in elevated prompt meaning cmd/powershell with administrative privileges that it👍🏼
Final command to run in cmd or powershell with admin rights :-
winget uninstall Microsoft.Winget.Source_8wekyb3d8bbwe
winget source reset --force
On reset windows ask to accept the agreement that it will detect location, accept it and that is it.
Is there any plan to revive appget?
