winget upgrade does not respect the scope used on installation

[JanDeDobbeleer]

Brief description of your issue

When using winget install in a non-elevated terminal, the installation is done with scope: user. However, when using upgrade immediately after in the same terminal window, the scope is identified as system.

Steps to reproduce

Install v27.17.0

winget install JanDeDobbeleer.OhMyPosh -v 24.17.0

2024-12-28 17:24:43.631 [CLI ] Starting installer selection.
2024-12-28 17:24:43.631 [CLI ] Installer [X64,msi,Machine,] is current best choice
2024-12-28 17:24:43.631 [CLI ] Installer [X64,msi,User,] is better [strong] than [X64,msi,Machine,] due to: Scope
2024-12-28 17:24:43.631 [CLI ] Installer [X64,msi,User,] is current best choice
2024-12-28 17:24:43.631 [CLI ] Installer [X64,msi,User,] is better [strong] than [X86,msi,Machine,] due to: Scope
2024-12-28 17:24:43.631 [CLI ] Installer [X64,msi,User,] is better [weak] than [X86,msi,User,] due to: Machine Architecture
2024-12-28 17:24:43.631 [CLI ] Installer [X64,msi,User,] is better [strong] than [Arm64,msi,Machine,] due to: Scope
2024-12-28 17:24:43.631 [CLI ] Installer [Arm64,msi,User,] is better [strong] than [X64,msi,User,] due to: Machine Architecture
2024-12-28 17:24:43.631 [CLI ] Installer [Arm64,msi,User,] is current best choice
2024-12-28 17:24:43.631 [CLI ] Completed installer selection.
2024-12-28 17:24:43.631 [CLI ] Selected installer Architecture: 4
2024-12-28 17:24:43.631 [CLI ] Selected installer URL: https://github.com/JanDeDobbeleer/oh-my-posh/releases/download/v24.17.0/install-arm64.msi
2024-12-28 17:24:43.631 [CLI ] Selected installer InstallerType: msi
2024-12-28 17:24:43.631 [CLI ] Selected installer Scope: User

Upgrade to latest

winget upgrade JanDeDobbeleer.OhMyposh

2024-12-28 17:26:57.914 [CLI ] Starting installer selection.
2024-12-28 17:26:57.914 [CLI ] Installer [X64,msi,Machine,] is current best choice
2024-12-28 17:26:57.914 [CLI ] Installer [X64,msi,User,] not applicable: Installer scope does not match currently installed scope: User != Machine
2024-12-28 17:26:57.914 [CLI ] Installer [X64,msi,Machine,] is better [weak] than [X86,msi,Machine,] due to: Machine Architecture
2024-12-28 17:26:57.914 [CLI ] Installer [X86,msi,User,] not applicable: Installer scope does not match currently installed scope: User != Machine
2024-12-28 17:26:57.914 [CLI ] Installer [Arm64,msi,Machine,] is better [strong] than [X64,msi,Machine,] due to: Machine Architecture
2024-12-28 17:26:57.914 [CLI ] Installer [Arm64,msi,Machine,] is current best choice
2024-12-28 17:26:57.914 [CLI ] Installer [Arm64,msi,User,] not applicable: Installer scope does not match currently installed scope: User != Machine
2024-12-28 17:26:57.914 [CLI ] Completed installer selection.
2024-12-28 17:26:57.914 [CLI ] Selected installer Architecture: 4
2024-12-28 17:26:57.914 [CLI ] Selected installer URL: https://github.com/JanDeDobbeleer/oh-my-posh/releases/download/v24.17.1/install-arm64.msi
2024-12-28 17:26:57.914 [CLI ] Selected installer InstallerType: msi
2024-12-28 17:26:57.914 [CLI ] Selected installer Scope: Machine

Expected behavior

It should also identify Installer [Arm64,msi,User,] is current best choice on upgrade.

Actual behavior

It identifies Installer [Arm64,msi,Machine,] is current best choice.

Full logs below.

WinGet-2024-12-28-17-26-54.424.log
WinGet-2024-12-28-17-24-39.755.log

Environment

Windows Package Manager v1.9.25200
Copyright (c) Microsoft Corporation. All rights reserved.

Windows: Windows.Desktop v10.0.26100.2605
System Architecture: Arm64
Package: Microsoft.DesktopAppInstaller v1.24.25200.0

Winget Directories                 
-----------------------------------------------------------------------------------------------------------------------
Logs                               %LOCALAPPDATA%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\Diag…
User Settings                      %LOCALAPPDATA%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\sett…
Portable Links Directory (User)    %LOCALAPPDATA%\Microsoft\WinGet\Links
Portable Links Directory (Machine) C:\Program Files\WinGet\Links
Portable Package Root (User)       %LOCALAPPDATA%\Microsoft\WinGet\Packages
Portable Package Root              C:\Program Files\WinGet\Packages
Portable Package Root (x86)        C:\Program Files (x86)\WinGet\Packages
Installer Downloads                %USERPROFILE%\Downloads

Links               
---------------------------------------------------------------------------
Privacy Statement   https://aka.ms/winget-privacy
License Agreement   https://aka.ms/winget-license
Third Party Notices https://aka.ms/winget-3rdPartyNotice
Homepage            https://aka.ms/winget
Windows Store Terms https://www.microsoft.com/en-us/storedocs/terms-of-sale

Admin Setting                             State
--------------------------------------------------
LocalManifestFiles                        Disabled
BypassCertificatePinningForMicrosoftStore Disabled
InstallerHashOverride                     Disabled
LocalArchiveMalwareScanOverride           Disabled
ProxyCommandLineOptions                   Disabled
DefaultProxy                              Disabled

[litmowise]

I have this related problem, using the winget upgrade command to upgrade a software programme results in two different versions.

[litmowise]

Updating with the winget upgrade command also results in one more set of environment variables.

First installation

current user env
C:\Users\xxx\AppData\Local\Programs\oh-my-posh\themes
C:\Users\xxx\AppData\Local\Programs\oh-my-posh\bin\

After updating

local machine env (system env)
C:\Program Files (x86)\oh-my-posh\themes
C:\C:\Program Files (x86)\oh-my-posh\bin\

[JanDeDobbeleer]

Updating with the winget upgrade command also results in one more set of environment variables.

@litmowise that's a side effect of the issue described above.

[litmowise]

@JanDeDobbeleer Thank you, I know.

[mdanish-kh]

This is a known issue with MSI / WiX installers where they would put uninstall entries in HKEY_LOCAL_MACHINE instead of HKEY_CURRENT_USER in the registry for user scoped installs. WinGet relies on the registry location to determine the installed scope. There's an open issue in the repo #3011 which suggests WinGet could have a better way to handle these scenarios

[davidldennison]

I was actually going to make an issue for this @denelon as I have this issue described with oh-my-posh as well as with other installations. I've been waiting until I had an example where I could submit to the Feedback Hub.

However, this might extend further into an issue of Winget not respecting paths and custom install locations, even sometimes failing to install into a custom directory using winget commands as it will just default back the installers preferred default location.

Will try and get an example soon!

[mdanish-kh]

This issue is not specific to oh-my-posh, but applies generally to most MSIs. I'll close this as duplicate of #3011

Duplicate of #3011

[JanDeDobbeleer]

@mdanish-kh is there anything I can change to the installer to force the identification?

[mdanish-kh]

@JanDeDobbeleer

Unfortunately, I don't think there's much you can do if you want to include both scopes in the manifest, unless you can tweak the user-scoped MSI installer to put the uninstall entries to HKCU instead of HKLM. Though, in my experience of reviewing most MSI manifests in winget-pkgs, I don't think I've encountered an MSI that puts install entries correctly to HKCU.

Alternatives

1. If it's possible, offer the old inno/exe based installers as well in addition to MSI. Users with user-scope can use the INNO distributions for upgrade. With this, MSI can only be used to offer machine scope variant.
2. Only offer machine scope in the manifest. Disadvantage being you don't offer user scope & the users who have installed user scope will get machine offered as an upgrade and they will end up with side-by-side install of oh-my-posh
3. Use winget upgrade with --force parameter. This tells WinGet to ignore the scope mismatch and just continue with installation, but may not be feasible or immediately obvious to all users

[mdanish-kh]

#3011 (comment) or https://stackoverflow.com/questions/32273217/how-and-why-installation-per-user-manages-to-write-to-hklm may offer some more hints

[mdanish-kh]

3. Use winget upgrade with --force parameter. This tells WinGet to ignore the scope mismatch and just continue with installation, but may not be feasible or immediately obvious to all users

I should also mention that here you'll have to explicitly target the user scope installer, as by default WinGet will assume the current installation is Machine

so: winget upgrade JanDeDobbeleer.OhMyPosh --scope user --force

[JanDeDobbeleer]

@mdanish-kh shouldn't that also work without the --force parameter in that case?

[mdanish-kh]

@JanDeDobbeleer No - Scope is treated as a requirement (instead of a preference) to be matched in case of upgrade. If WinGet detects current installation as Machine, doing winget upgrade --scope user would fail with No applicable upgrade found unless you explicitly ask WinGet to ignore the requirement with --force

[Dilant]

@mdanish-kh Tried winget upgrade JanDeDobbeleer.OhMyPosh --scope user --force and it didn't work for me. It still says "no package found matching input criteria".

# Dilant @ Dilant-PC in ~ [16:28:11]
$ winget --version
v1.9.25200

# Dilant @ Dilant-PC in ~ [16:32:33]
$ winget upgrade JanDeDobbeleer.OhMyPosh --scope user --force
找不到与输入条件匹配的已安装程序包。

[JanDeDobbeleer]

It still says "no package found matching input criteria".

@Dilant same for me, this is a really annoying bug TBH.

@mdanish-kh this issue has been open for almost 2 years and seems rather fundamental for a package manager to get right. I would expect that when using --scope user this only implies to use the correctly provided flags in the manifest, and not go on some sort of magic hunt to determine what to do.

@denelon something we can do about this? I would be bummed to have to go back to the Inno installer simply because of this bug.

[denelon]

I'll talk with the team about this "class" of issue today

I'll put some notes over in:

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

[JanDeDobbeleer]

@denelon if there's something we can do installer side to facilitate the correct detection, let me know. Registry values can be set rather easily. That way it doesn't matter if the user installed using winget, upgraded manually etc...

[denelon]

@JanDeDobbeleer yes, you should be able to get the installer to write the keys to HKCU for user and to HKLM for a system wide install. The package manifest would need to have two "installers" one with each scope. For an initial "install" flow, WinGet would default to "user" unless the scope was passed to WinGet. For the upgrade flow, WinGet would inspect the registry to run the upgrade flow appropriately afterwards to match the currently installed scope.

[JanDeDobbeleer]

@denelon I'm trying to hack this in, but even when adding the registry information to HKCU, winget still thinks it's machine scope. I am unable to remove these from HKLM as that would require elevation and this is done by msiexec. I do not understand why winget needs to magically identify this when you know which scope was used by the user previously (or fallback to the same logic you use on install).