Allow WINGET to automatically change installer technologies instead of installing with error #6459

Activity

1. krezol

   added

   Issue-FeatureThis is a feature request for the Windows Package Manager client.This is a feature request for the Windows Package Manager client.

   Needs-TriageIssue needs to be triagedIssue needs to be triaged

   on Aug 12, 2026
2. krezol

   added the

   Feature

   issue type on Aug 12, 2026
3. github-actions

   added

   Possible-DuplicateAutomatically surfaced as a likely duplicate of an existing issue; awaiting maintainer confirmation.Automatically surfaced as a likely duplicate of an existing issue; awaiting maintainer confirmation.

   on Aug 12, 2026
4. github-actions commented on Aug 12, 2026

   

   github-actionsBot

   on Aug 12, 2026 – with GitHub Actions

   More actions

   Possible duplicate(s):

   Thank you for submitting this issue.

   The issue(s) below may already track your request or bug. Please take a look — if one of them matches, give that issue a 👍 and close this one as a duplicate. Older or curated issues are preferred as the canonical one to follow.

   • Improve winget upgrade --all with installer mismatch #2883 — Requests improved handling when winget upgrade --all encounters installer technology mismatch (feature request by a maintainer with the same core ask)
   • winget upgrade --all lists and silently skips app with different installer technology #3817 — Reports that winget upgrade --all silently skips packages with different installer technology, with the same proposed fix of uninstalling and reinstalling
   • Upgrade claims installer type changed while it hasn't #3295 — Upgrade claims installer type changed; discusses the same "install technology is different" error and workarounds
   • Microsoft Edge: install technology is different from the current version installed #4159 — Concrete example of the "install technology is different" error blocking an upgrade, requesting automatic resolution

   Template: msftbot/duplicate/surfaced by Duplicate Surfacing
5. tonicofonico commented on Aug 27, 2026

   

   tonicofonico

   on Aug 27, 2026

   More actions

   Adding real-world reproduction cases with recent manifests:

   1. **\JanDeDobbeleer.OhMyPosh**:

      • Installed: legacy WiX/MSI package (\29.26.0\ / {31FCBFFC-F401-4B47-84F3-A266659D706C}).
      • Available in manifest: \30.9.0\ packaged as \msix\ (\install-x64.msix).
      • Outcome: \winget upgrade --all\ is hard-blocked with the error:
        \2 pacchetti hanno aggiornamenti bloccati perché le versioni più recenti utilizzano una tecnologia di installazione diversa rispetto all'installazione corrente. Disinstalla ogni pacchetto, quindi installa la versione più recente.\

   2. **\dokan-dev.Dokany**:

      • Installed: Burn/EXE bundle (\1.4.1.1000).
      • Available in manifest: WiX/MSI package (\2.3.1.1000).
      • Outcome: Same hard block on \winget upgrade --all.

   Having an automated migration flag (e.g. \winget upgrade --allow-installer-type-change\ or \winget upgrade --migrate-installer-type) that uninstalls the legacy installer type and installs the new type cleanly would avoid manual registry/MsiExec cleanup.
6. denelon commented on Sep 1, 2026

   

   Demitrius Nelon (denelon)

   on Sep 1, 2026

   Collaborator

   More actions

   There are situations where automatically doing the uninstall/install causes user data loss.
   If I had an MSI and a bunch of settings/package specific files, they could get lost during uninstallation. The new MSIX variation wouldn't know how to migrate my settings or data.
7. Demitrius Nelon (denelon)

   removed

   Needs-TriageIssue needs to be triagedIssue needs to be triaged

   on Sep 1, 2026
8. krezol commented on Sep 1, 2026

   

   krezol

   on Sep 1, 2026

   Author

   More actions

   How about if package maintainers were responsible for providing an upgrade script to handle the settings migration? Or maybe another flag --do-not-preserve-settings-during-installer-migration ?