microsoft/winget-cli

`winget upgrade oh-my-posh --version 27.1.2` installs a second copy of the app instead of upgrading it

Opened this issue · 6 comments

sba923 commented

Relevant area(s)

WinGet CLI

Relevant command(s)

winget upgrade

Brief description of your issue

Context:

JanDeDobbeleer.OhMyPosh version 26.23.8 was installed machine-wide using an MSI, and my machines are configured to install machine-wide by default:

    "installBehavior": {
        "preferences": {
            "scope": "machine",
            "architectures": ["x64"]
        }
    }

Version 27.1.2's manifest specifies that MSIX installation is preferred, and this only supports per-user installation.

The problem:

Running winget upgrade oh-my-posh --version 27.1.2 on a machine with 26.23.8 installed machine-wide doesn't upgrade the existing app, but instead installs a second copy.

The result is:

PS❯ winget list JanDeDobbeleer.OhMyPosh
Name       Id                      Version Source
--------------------------------------------------
Oh My Posh JanDeDobbeleer.OhMyPosh 27.1.2  winget
Oh My Posh JanDeDobbeleer.OhMyPosh 26.23.8 winget
PS❯ gcm oh-my-posh -all

CommandType     Name                                               Version    Source
-----------     ----                                               -------    ------
Application     oh-my-posh.exe                                     26.23.8.0  C:\Program Files (x86)\oh-my-posh\bin\oh-my-posh.exe
Application     oh-my-posh.exe                                     27.1.2.0   C:\Users\<REDACTED>\AppData\Local\Programs\oh-my-posh\bin\oh-my-posh.exe

Steps to reproduce

  1. Install JanDeDobbeleer.OhMyPosh version 26.23.8 machine-wide
  2. Run winget upgrade oh-my-posh --version 27.1.2

Expected behavior

Version 27.1.2 should replace version 26.23.8

Actual behavior

Version 27.1.2 is installed per-user next to version 26.23.8. And the latter is first on the PATH, so the new version isn't used.

Environment

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

Windows: Windows.Desktop v10.0.19045.6396
System Architecture: X64
Package: Microsoft.DesktopAppInstaller v1.26.430.0

Winget Directories
-------------------------------------------------------------------------------------------------------------------------------
Logs                               %LOCALAPPDATA%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\DiagOutputDir
User Settings                      %LOCALAPPDATA%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\settings.json
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
Configuration Modules              %LOCALAPPDATA%\Microsoft\WinGet\Configuration\Modules

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
github-actions commented

The following issues might be duplicates:

AI-generated content by genai-issue-dedup may be incorrect.

denelon commented

WinGet is attempting to match the package in a manifest with the installed "installer type" when the upgrade command is used. In situations where a different installer type is present and the "original" installer type is not, the user gets prompted to uninstall the previous version and install the "new" version (an MSI and an MSIX are not the same package to Windows).

I did test with the MSI installed and when I ran upgrade, the MSI was upgraded. I did this in the user context as opposed to an MSI installed for all users. I'll have to see if I can reproduce this behavior to see if we can isolate where the problem is.

@JanDeDobbeleer FYI.

denelon commented

I wasn't able to reproduce the issue:

Image
denelon commented

I did however find another interesting case where my "upgrade" was run as user as opposed to machine and I ended up with two versions installed.

Image
denelon commented

@JohnMcPMS does this look like a WinGet bug to you?

sba923 commented

I did however find another interesting case where my "upgrade" was run as user as opposed to machine and I ended up with two versions installed.

That's exactly what I have reported.

BTW, I think winget should warn the user if the config file specifies machine scope and the installation ends up being per-user. Or maybe even fail -- which it should do if the command line specifies machine scope and this can't be done.