microsoft / microsoft/winget-cli

Upgrade with UpgradeBehavior: uninstallPrevious ignores newly added installer types on existing installs

Open
#5,453 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Command-Upgrade Issue-Bug
Dominant language
C++
Stars
26.4k
Forks
1.8k
Avg merge
1d 11h
Merged PRs (30d)
15

Description

Brief description of your issue

When a package originally installed with one installer type (e.g., Inno) is updated to include a new installer type (e.g., portable/zip) and UpgradeBehavior: uninstallPrevious is set, winget upgrade will uninstall and then re-install the same original installer type—ignoring both the new entry and the manifest’s installer ordering. Fresh installs of the updated manifest correctly pick the new installer, but existing installations do not.

Steps to reproduce
  1. Initial Install
    Create a manifest containing only the Inno installer and install it.
  2. Update Manifest
    Update the manifest, add the portable (zip → nested portable) installer first, and set UpgradeBehavior: uninstallPrevious at the top-level.
  3. Upgrade
    Upgrade the installed package using the new manifest.
Expected behavior

With UpgradeBehavior: uninstallPrevious, the originally installed Inno package is uninstalled and then the newly defined portable installer (zip → nested portable) is selected (per manifest order or user preference) and installed.

Actual behavior
  • winget upgrade uninstalls the Inno-based package and re-installs the same Inno installer.
  • The new portable installer entry is ignored for existing installs, despite appearing first in the manifest and despite setting UpgradeBehavior: uninstallPrevious
Environment
Windows Package Manager v1.10.390
Copyright (c) Microsoft Corporation. All rights reserved.

Windows: Windows.Desktop v10.0.26100.3915
System Architecture: X64
Package: Microsoft.DesktopAppInstaller v1.25.390.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                X:\Users\Daniel\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                        Enabled
BypassCertificatePinningForMicrosoftStore Disabled
InstallerHashOverride                     Disabled
LocalArchiveMalwareScanOverride           Disabled
ProxyCommandLineOptions                   Disabled
DefaultProxy                              Disabled
Additional Context

Scope: Only affects packages where the existing installation predates the addition of the new installer type.

Related Issues

#4677

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reproducing the upgrade flow with an initial Inno-only manifest, then an updated manifest placing the portable installer first and setting UpgradeBehavior: uninstallPrevious. Trace the existing-install upgrade path and verify that done means the old Inno package is removed and the newly ordered portable installer is selected for installation.

Written by the indexing model from the issue text.

Assessment

Tech stack
cpp
Domain
cli
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
38/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.