Open HeinVG opened 2 years ago
Do you see other packages in winget list
that could account for the difference? I'm wondering if it's related to another source.
@denelon you might have nailed it, I'm seeing the 8 packages with unknown version there, 3 coming from winget while the rest don't (some are Steam games just to give you an idea of what's seeing).
I took a quick look at the code and saw two possible sources for inconsistencies with the unknown count
When listing available upgrades we first filter the unknown installed versions and count them there, but we may later remove other packages that are not available from any source. So the count of unknown includes those un-available packages that are not listed with --include-unknown. That's probably what happened here.
When performing the upgrades we first filter the unknown versions and count them there, but we later remove packages where the update is not applicable (e.g., mismatched architecture). So the count of unknown includes the non-applicable updates that are not applied with --include-unknown.
Related to:
Just wanted to share I am facing the same issue.
Here's my output.
$ winget upgrade --all
Name Id Version Available Source
--------------------------------------------------------------------------------------------------------------------
Rancher Desktop 1.8.1 suse.RancherDesktop 1.8.1 1.11.1 winget
JetBrains Gateway JetBrains.Gateway > 2022.3.2 2023.3.2 winget
RustRover JetBrains.RustRover 2023.2 EAP 2023.2 winget
Notion 2.0.23 Notion.Notion 2.0.23 3.1.0 winget
Microsoft Visual C++ 2010 x86 Redistributable - 10.0.30319 Microsoft.VCRedist.2010.x86 10.0.30319 10.0.40219 winget
PowerShell 7.2.17.0-x64 Microsoft.PowerShell 7.2.17.0 7.4.0.0 winget
6 upgrades available.
Installing dependencies:
(1/1) Found Notion [Notion.Notion] Version 3.1.0
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://desktop-release.notion-static.com/Notion%20Setup%203.1.0.exe
██████████████████████████████ 79.4 MB / 79.4 MB
Successfully verified installer hash
Starting package install...
Successfully installed
1 package(s) have version numbers that cannot be determined. Use --include-unknown to see all results.
We've been working on the side-by-side scenarios. You could try the latest release and enable the experimental feature on:
Please provide feedback at:
This was bugging me for a while. Then I entered winget list | Where-Object { $_ -match 'Unknown' }
and realised games installed with the Steam client (many of them since uninstalled) were polluting the list.
So many entries like: "ARP\Machine\X64\Steam App 219150"
Is the behavior with WinGet 1.8 better? We've added better support for side-by-side installed packages.
Currently I'm running version v1.9.1792-preview, the behavior is somewhat strange:
I'm seeing that winget is listing Steam games as well like @metamec shared with. Overall the experience is better but as an end user I'm a bit confused if this is the expected behavior or not.
The steam games are reported in the registry, so listing them would be expected behavior.
The steam games are reported in the registry, so listing them would be expected behavior.
I have currently 3 games installed from the Steam library, so the number corresponds to that.
Brief description of your issue
When running winget upgrade to update packages on my Windows 11 system, I'm running into the following behavior:
As you can see in the screenshot above, winget says there's 8 packages with version numbers it can't be determined, but using the flag of --include-unknown to list them all shows only 3
Steps to reproduce
Run "winget upgrade --all" let it install all upgrades/updates and check for the output of how many packages are missing
Expected behavior
It should match the same number of packages when you'll run "winget upgrade --include-unknown"
Actual behavior
The number of packages with version numbers that can't be determined are mismatching
Environment