Closed Trenly closed 2 years ago
Per discussion in the gitter channel, it seems like winget is not checking to see if there is a version of the app in the repository before putting it into the count of unknown packages. So if there isn't something in the repo to "update" to, then it shouldn't add it to the count.
Shouldn't be that hard to fix, I'll try to write one if nobody else does.
WinDirStat is a package where this is true, as winget can't find a eligible package during upgrade due to another upgrade bug.
Another case that this happens is Nirsoft.BlueScreenView
Edit: Seems like there is also a second portion to this bug that even if --include-unknown
is used, it doesn't check to see if there is a version available in the repo. It just always skips checking for upgrades entirely?
It just always skips checking for upgrades entirely?
Not always, GOG shows up as available for upgrade with --include-unknown
. I think there's some criteria these apps are missing, but I'm not sure what it is.
❯ winget upgrade
Name Id Version Available
----------------------------------------------------
Oh My Posh JanDeDobbeleer.OhMyPosh 7.17.0 7.18.0
1 upgrades available.
12 packages have version numbers that cannot be determined. Use "--include-unknown" to see all results.
❯ winget list
Name Id Version
----------------------------------------------------------------------------------------------------------------
Battle.net Battle.net Unknown
Call of Duty Black Ops Cold War Call of Duty Black Ops Cold War Unknown
Call of Duty Modern Warfare Call of Duty Modern Warfare Unknown
DuckieTV DuckieTV Unknown
ReaPlugs/x64 ReaPlugs Unknown
New World Steam App 1063730 Unknown
Forza Horizon 5 Steam App 1551360 Unknown
Sid Meier's Civilization VI Steam App 289070 Unknown
Factorio Steam App 427520 Unknown
PUBG: BATTLEGROUNDS Steam App 578080 Unknown
Trackmania Uplay Install 5595 Unknown
VBCABLE, The Virtual Audio Cable VB:VBCABLE {87459874-1236-4469} Unknown
I see you guys talking about BlueScreenView and WinDirStat, the reason these are getting picked up is because it doesn't match the metadata because the Publisher is blank and its missing the ProductCode 🙃
I'm having a similar issue.
`> winget upgrade --all
No installed package found matching input criteria.
2 packages have version numbers that cannot be determined. Use "--include-unknown" to see all results.
No applicable update found.
2 packages have version numbers that cannot be determined. Use "--include-unknown" to see all results.`
`> winget upgrade
No installed package found matching input criteria. 2 packages have version numbers that cannot be determined. Use "--include-unknown" to see all results.`
`> winget upgrade --include-unknown
No installed package found matching input criteria.`
Something is broken here.
Having this issue currently. Is there any fix?
Thanks in Advance.
Run "winget upgrade --include-unknown and show the results. If you don't have any that can be upgraded currently, adding include-unknown isn't going to change anything
But is there any way to remove the line and get it to stop checking the package?
There are several edge cases confounding the upgrade logic in WinGet. They range from inconsistent versioning behavior to no version being reported. We also have packages that do a better job of upgrading themselves due to services running or other packages using their libraries.
In order to have the best possible experience with winget upgrade --all
we've started excluding some of the packages from the default flow. The additional arguments give additional control back to the user.
In some cases, running winget list
will help narrow down whether the installed version reports "Unknown" for the version (meaning no registry entry was written for the version). In other cases, the installer type changed from .exe, MSI, or MSIX to a different one. In those cases, the other installer type isn't technically an upgrade, but a new side-by-side installation.
There are also cases where the scope or architecture doesn't match. These can be compounded by user preferences or requirements in settings.
We're working to improve the messaging displayed to users to help with some of the confusion.
We're also working on package pinning to help prevent unwanted upgrades.
I agree that the message is quite misleading. It stated "Use --include-unknown
to see all results", but when we use --include-unknown
, no result is shown at all. An improvement to the message displayed would be great indeed.
I wrote that, I agree it is somewhat confusing. Maybe since we have the package index by time we do the "lets filter out all the unknown versions" part, we could just only show the "use --include-unknown" part if any of the unknown version packages actually exist in the repo.
Brief description of your issue
When running
winget upgrade
it tells me a package has unknown version. When using--include-unknown
the package with unknown version is not listed and the upgrade list does not changeSteps to reproduce
Have a package with unknown version, run
winget upgrade --include-unknown
Expected behavior
A list of all upgradeable packages to be shown
Actual behavior
The list of packages does not change between
winget upgrade
andwinget upgrade --unknown
Logs attached for reference.WinGet-2022-02-14-19-58-27.679_upgrade.log WinGet-2022-02-14-19-58-35.901_IncludeUnknown.log
Environment