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

[DanTheMan827]

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

[Trenly]

I believe this is intentional, where UpgradeBehavior only applies once the installer has been selected and the upgrade has started, to prevent the case where a user has intentionally selected one installer type and that installer type is no longer available. There is the --uninstall-previous switch which is meant to bypass the check for InstallerType, but it currently is not working

• https://github.com/microsoft/winget-cli/issues/5136