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?