Winget incorrectly detects per-user MSI scope (`No applicable update found`)

sitiom commented 1 year ago

Brief description of your issue

I cannot upgrade packages whose MSI installers are under user scope. A No applicable update found is shown despite it showing to be available from the winget upgrade command.

Here are some examples of packages with this issue:

Google.IAPDesktop
PDFArranger.PDFArranger
Dummerle.Rare
Mu.Mu
RussellBanks.Komac

Steps to reproduce

Install an old version of one of the packages above. For this example, we will use RussellBanks.Komac.
Check available updates via winget upgrade. Komac should show up.
Upgrade the package (winget upgrade RussellBanks.Komac)
See No applicable upgrade found. message.

Log:

2023-02-20 21:31:17.269 [CORE] WinGet, version [1.5.441-preview], activity [{5406AEB0-B779-484D-B465-C2A2EF98C06A}]
2023-02-20 21:31:17.270 [CORE] OS: Windows.Desktop v10.0.25284.1000
2023-02-20 21:31:17.270 [CORE] Command line Args: "C:\Users\vedan\AppData\Local\Microsoft\WindowsApps\winget.exe" upgrade --id RussellBanks.Komac --exact -s winget --open-logs
2023-02-20 21:31:17.270 [CORE] Package: Microsoft.DesktopAppInstaller v1.20.441.0
2023-02-20 21:31:17.270 [CORE] IsCOMCall:0; Caller: winget-cli
2023-02-20 21:31:17.278 [CLI ] WinGet invoked with arguments: 'upgrade' '--id' 'RussellBanks.Komac' '--exact' '-s' 'winget' '--open-logs'
2023-02-20 21:31:17.278 [CLI ] Found subcommand: upgrade
2023-02-20 21:31:17.278 [CLI ] Leaf command to execute: root:upgrade
2023-02-20 21:31:17.294 [CLI ] Executing command: upgrade
2023-02-20 21:31:17.309 [REPO] Named source requested, found: winget
2023-02-20 21:31:17.325 [CORE] Examining extension: PFN = Microsoft.Winget.Source_8wekyb3d8bbwe, ID = IndexDB
2023-02-20 21:31:17.325 [CORE] Found matching extension.
2023-02-20 21:31:17.375 [REPO] Opening SQLite Index for ImmutableRead at 'C:\Program Files\WindowsApps\Microsoft.Winget.Source_2023.220.1651.303_neutral__8wekyb3d8bbwe\Public\index.db'
2023-02-20 21:31:17.375 [SQL ] Opening SQLite connection #1: 'C:\Program Files\WindowsApps\Microsoft.Winget.Source_2023.220.1651.303_neutral__8wekyb3d8bbwe\Public\index.db' [1, 40]
2023-02-20 21:31:17.377 [REPO] Opened SQLite Index with version [1.6], last write [2023-02-20 21:21:06.000]
2023-02-20 21:31:17.686 [REPO] Creating PredefinedInstalledSource with filter [None]
2023-02-20 21:31:17.686 [REPO] Creating new SQLite Index [4294967295.4294967295] at ':memory:'
2023-02-20 21:31:17.686 [SQL ] Opening SQLite connection #2: ':memory:' [6, 0]
2023-02-20 21:31:17.757 [REPO] Reading MSI UpgradeCodes
2023-02-20 21:31:17.758 [REPO] Examining ARP entries for Machine | X64
2023-02-20 21:31:17.776 [REPO] Examining ARP entries for Machine | X86
2023-02-20 21:31:17.854 [REPO] Reading MSI UpgradeCodes
2023-02-20 21:31:17.856 [REPO] Examining ARP entries for User | X64
2023-02-20 21:31:18.315 [REPO] Opening SQLite Index for ReadWrite at 'C:\Users\vedan\AppData\Local\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\Microsoft.Winget.Source_8wekyb3d8bbwe\installed.db'
2023-02-20 21:31:18.315 [SQL ] Opening SQLite connection #3: 'C:\Users\vedan\AppData\Local\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\Microsoft.Winget.Source_8wekyb3d8bbwe\installed.db' [2, 0]
2023-02-20 21:31:18.317 [REPO] Opened SQLite Index with version [1.6], last write [2023-02-20 20:30:49.000]
2023-02-20 21:31:18.406 [CLI ] Found one app. App id: RussellBanks.Komac App name: Komac
2023-02-20 21:31:18.409 [REPO] Downloading manifest
2023-02-20 21:31:18.409 [CORE] WinINet downloading from url: https://cdn.winget.microsoft.com/cache/manifests/r/RussellBanks/Komac/1.0.4/d166-RussellBanks.Komac.yaml
2023-02-20 21:31:18.459 [CORE] Download hash: 59432829da366f7f6275dad785f4b8495ab9dfc19817ecc2fb8905255038d794
2023-02-20 21:31:18.459 [CORE] Download completed.
2023-02-20 21:31:18.461 [CLI ] Starting installer selection.
2023-02-20 21:31:18.461 [CLI ] Installer [X64,burn,User,en-US] not applicable: Installer scope does not match currently installed scope: User != Machine
2023-02-20 21:31:18.461 [CLI ] Installer [X64,burn,User,en-US] not applicable: Installed package type 'msi' is not compatible with installer type burn
2023-02-20 21:31:18.479 [CLI ] Terminating context: 0x8a15002b at D:\a\_work\1\s\external\pkg\src\AppInstallerCLICore\Workflows\UpdateFlow.cpp:a6

Expected behavior

It should successfuly start to upgrade the package.

Actual behavior

A No applicable upgrade found. message is shown despite an upgrade being available.

Environment

Windows Package Manager (Preview) v1.5.441-preview

Windows: Windows.Desktop v10.0.22621.1265
System Architecture: X64
Package: Microsoft.DesktopAppInstaller v1.20.441.0

Masamune3210 commented 1 year ago

Its telling you that no applicable update is found because the installer types and scopes are not compatible with each other.

Upgrades are only supported if the scopes match and the installers are directly compatible with each other iirc.

sitiom commented 1 year ago

Upgrades are only supported if the scopes match and the installers are directly compatible with each other iirc.

Yes, but in this case it should match. Winget is saying that the installer is in the machine scope when it really is user scope.

mdanish-kh commented 1 year ago

MSIs by default install in machine scope IIRC. To have them install in user scope, you would have to provide additional InstallerSwitches ALLUSERS=2 MSIINSTALLPERUSER=1 in the manifest.

Ref: MSIINTALLPERSUSER Property

You could see these switches are added to separate the two scopes in the manifest for Microsoft.RemoteDesktopClient

But not all MSI installers (the one that comes at the top of my head is Microsoft.PowerShell) support per-user installation. So, I guess it's a matter of testing whether an MSI installer supports per-user installation, and if does you would need to add the necessary InstallerSwitches in the manifest.

sitiom commented 1 year ago

The packages mentioned above are user-scoped only. See also https://github.com/russellbanks/Komac/issues/103#issuecomment-1445342342:

That has no effect on the behavior of the installer. The install does write to that location, but the uninstall strings are still located in HKLM (HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{GUID})

To confirm that the issue is still present:

ItzLevvie commented 1 year ago

Winget is saying that the installer is in the machine scope when it really is user scope.

I ran into this issue last year when adding Scope to a lot of manifests.

WinGet determines a per-user install vs machine-wide install based on where the registry entries are placed instead of the where the application is installed to.

Some installers will install in per-user but have its registry entries in HKLM and some installers will install in per-machine but have its registry entries in HKCU. This is because the installer places its registry entries in the wrong place.

Komac does a per-user install but places all of its registry entries in HKLM (which is meant for machine-wide installs) so WinGet will immediately think that Komac is a machine-wide install because of this. Komac will need to place registry entries in HKCU to be considered a per-user install to WinGet.

sitiom commented 1 year ago

Can you point to me a per-user only MSI installer that properly places the registry in the HKCU? So far the packages that I have found all install in HKLM and have the same problem.

Trenly commented 1 year ago

Komac does a per-user install but places all of its registry entries in HKLM (which is meant for machine-wide installs) so WinGet will immediately think that Komac is a machine-wide install because of this. Komac will need to place registry entries in HKCU to be considered a per-user install to WinGet.

@russellbanks

russellbanks commented 1 year ago

I invoke jPackager from the JDK for this, which uses Wix for exe's and msi's. I use InstallScope="perUser" Platform="x64", so I don't know whether this is Java or Wix that is putting it in the wrong place.

sitiom commented 1 year ago

I use InstallScope="perUser" Platform="x64", so I don't know whether this is Java or Wix that is putting it in the wrong place.

Or it's by design: https://stackoverflow.com/questions/32273217/how-and-why-installation-per-user-manages-to-write-to-hklm. Winget should have some sort of special detection for this one.

ItzLevvie commented 1 year ago

Can you point to me a per-user only MSI installer that properly places the registry in the HKCU?

I don't think I remember seeing one when I installed more than 3000+ applications from WinGet into a Microsoft Azure VM.

If it's a WIX bug then it's best to file an issue over at their repository to check if it's intentional or not. Developers of WIX are also in the process of rewriting its entire project (https://github.com/wixtoolset/wix4) which is currently in alpha so there might be a possibility that it might be fixed over there.

Though I will say that this issue seems a lot more common on EXE installers than MSI installers since there are more than 100+ packages that are affected by this issue.

Some examples are:

This could probably be solved if WinGet had support for Scope in AppsAndFeaturesEntries where the Scope in AppsAndFeaturesEntries can be used to trick WinGet into thinking that a per-user install with registry entries in HKLM is a per-user install or something along those lines.

sitiom commented 1 year ago

If it's a WIX bug then it's best to file an issue over at their repository to check if it's intentional or not. Developers of WIX are also in the process of rewriting its entire project (wixtoolset/wix4) which is currently in alpha so there might be a possibility that it might be fixed over there.

@robmen Sorry for the ping, but can we get your advice from here? Does Windows Installer really write to HKLM regardless of install scope, and what is the proper way to detect installation context from MSIs?