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

[sitiom]

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

1. Install an old version of one of the packages above. For this example, we will use RussellBanks.Komac.
2. Check available updates via winget upgrade. Komac should show up.
3. Upgrade the package (winget upgrade RussellBanks.Komac)
4. 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]

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]

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]

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]

The packages mentioned above are user-scoped only. See also russellbanks/Komac#103 (comment):

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]

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]

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]

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]

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]

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]

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:

• [Scope] Honeygain.Honeygain - No applicable update found winget-pkgs#47777
• [Scope] Gridcoin.Client - No applicable update found winget-pkgs#47655
• Fix Scope for SumatraPDF.SumatraPDF version 3.2 winget-pkgs#46366

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]

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?

• [Scope] Honeygain.Honeygain - No applicable update found winget-pkgs#47777

Honeygain seems to be already deleted from winget-pkgs (microsoft/winget-pkgs#60711)

• [Scope] Gridcoin.Client - No applicable update found winget-pkgs#47655

Nullsoft installers can be fixed:

• build(nsis): Write registry keys to HKLM instead of HKCU, Install shortcuts for all users, Fix INSTALLDIR removal bug gridcoin-community/Gridcoin-Research#2643

The issue at hand here is about MSI installers.

• Fix Scope for SumatraPDF.SumatraPDF version 3.2 winget-pkgs#46366

SumatraPDF seems to be already properly behaving now:

[robmen]

Windows Installer doesn't document its use of the registry. Use the MSI APIs, like MsiGetProductInfoExW.