`winget uninstall Microsoft.Aspire` fails on dogfood `LocalManifestFiles` installs (exit -1978335212)

[radical]

Summary

winget uninstall --id Microsoft.Aspire and eng/winget/dogfood.ps1 -Uninstall both fail with exit code -1978335212 (APPINSTALLER_CLI_ERROR_NO_APPLICABLE_INSTALLER / "the input value is invalid") when the Aspire install was created via the dogfood LocalManifestFiles path. The recorded source for a dogfood install ends with __DefaultSource rather than _Microsoft.Winget.Source_8wekyb3d8bbwe, and winget's uninstall lookup doesn't resolve Microsoft.Aspire against that source identifier the same way.

Manual cleanup currently requires removing three pieces by hand:

Remove-Item $pkgDir -Recurse -Force      # %LOCALAPPDATA%\Microsoft\WinGet\Packages\Microsoft.Aspire__DefaultSource
Remove-Item $link -Force                 # %LOCALAPPDATA%\Microsoft\WinGet\Links\aspire.exe
Remove-Item $arpKey -Recurse -Force      # HKCU:\Software\Microsoft\Windows\CurrentVersion\Uninstall\Microsoft.Aspire__DefaultSource

This is awkward for anyone running the dogfood path repeatedly (PR validation, CI runs of prepare-installer-artifacts.yml, developer iteration). It also leaves contributors who attempt winget uninstall confused about why it didn't work.

What should happen

eng/winget/dogfood.ps1 -Uninstall should detect the __DefaultSource install shape and tear it down via the same three-step manual cleanup, rather than relying on winget uninstall. If winget itself has a documented way to uninstall a LocalManifestFiles install in newer releases, prefer that.

Possibly out of our control

The root cause may be in winget-cli rather than in our scripts — winget uninstall arguably should work against any package it can find in the ARP registry regardless of source identifier. If so, file upstream at https://github.com/microsoft/winget-cli and have dogfood.ps1 -Uninstall work around it in the meantime.

Context

Surfaced while writing the Windows test runbook for #17919. The full followups doc is at PR #17919 comment.

[joperezr]

🤖 Aspire triage pass — 2026-06-05 07:01 UTC

Area: area-engineering-systems
Kind: bug
Repro: yes-minimal — see the Summary and manual-cleanup snippet in the issue body
Affected version(s): dogfood LocalManifestFiles installs via eng/winget/dogfood.ps1 (internal/CI tooling, not a shipped release)
Severity: S4 — affects internal dogfood / PR-validation workflow only; workaround documented inline (three Remove-Item commands)

Urgency: ⚪ backlog — no milestone
Reason: internal dev/CI tooling fix; no user impact on shipped Aspire. Root cause may live upstream in winget-cli per the reporter's own analysis.

Suggested owner(s): @joperezr (score: top non-author human contributor in area-engineering-systems over last 90d)
Evidence:

• @joperezr merged Merge release/13.4 to main after v13.4.0 release #17817 and Merge release/13.3 to main after v13.3.5 release (supersedes #17337) #17343 in area-engineering-systems recently
• The dominant recent contributor in this area is the issue reporter @radical (e.g. Unblock WinGet Manifest job on locked-down 1ES agents; update manifest tags #17913, Avoid empty test summary artifact URL #16478, Add LocalArchive + DotnetTool CLI install modes for E2E tests #16454, feat(ci): add test failure retry support to auto-rerun workflow #16446, Publish and sign CLI install scripts #15127, [CI] Fix randomly failing tests on azdo due to docker+testcontainers/ryuk issues #15111, Automatically rerun transient CI failures #15110, [CI] Update to newer linux image on internal pipeline #15055, Reduce the number of PR validation jobs #15031, Reduce PR validation time by decoupling CLI archive dependencies #15023), who is excluded as owner
• Bots (aspire-repo-bot, copilot-swe-agent) also excluded

Confidence: medium
Needs human?: no

Dry-run mode — no labels or milestone applied. Reply /triage apply to promote, or edit and reapply.