microsoft / winget-cli

WinGet is the Windows Package Manager. This project includes a CLI (Command Line Interface), PowerShell modules, and a COM (Component Object Model) API (Application Programming Interface).
https://learn.microsoft.com/windows/package-manager/
MIT License
23.3k stars 1.45k forks source link

--include-unknown shows a lower number of packages after running "winget upgrade --all" #2458

Open HeinVG opened 2 years ago

HeinVG commented 2 years ago

Brief description of your issue

When running winget upgrade to update packages on my Windows 11 system, I'm running into the following behavior:

image

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

winget --info:
Windows Package Manager (Preview) v1.4.2161-preview
Copyright (c) Microsoft Corporation. All rights reserved.

Windows: Windows.Desktop v10.0.22621.382
System Architecture: X64
Package: Microsoft.DesktopAppInstaller v1.19.2161.0

Logs: %LOCALAPPDATA%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\DiagOutputDir

-- 
OS Name:                   Microsoft Windows 11 Pro
OS Version:                10.0.22621 N/A Build 22621
denelon commented 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.

HeinVG commented 2 years ago

@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).

florelis commented 2 years ago

I took a quick look at the code and saw two possible sources for inconsistencies with the unknown count

  1. 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.

  2. 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.

denelon commented 1 year ago

Related to:

albertocavalcante commented 10 months ago

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.
denelon commented 7 months ago

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:

metamec commented 4 months ago

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"

denelon commented 4 months ago

Is the behavior with WinGet 1.8 better? We've added better support for side-by-side installed packages.

HeinVG commented 4 months ago

Currently I'm running version v1.9.1792-preview, the behavior is somewhat strange:

image

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.

denelon commented 4 months ago

The steam games are reported in the registry, so listing them would be expected behavior.

Pepo48 commented 1 month ago

The steam games are reported in the registry, so listing them would be expected behavior.

Image

I have currently 3 games installed from the Steam library, so the number corresponds to that.