Summary
When multiple Aspire CLI installation methods coexist (WinGet, release script, PR dogfood script), removing one install doesn't clean up its side effects. This leaves stale configuration that silently breaks the remaining installs.
Problem
All Aspire CLI binaries share the same ~/.aspire/ config directory regardless of installation method. When a script or PR install is removed (by deleting the binary), the remaining install (e.g., WinGet) inherits stale config:
- PR install leaves behind:
channel = pr-NNNNN in global config, hive directory (~/.aspire/hives/pr-NNNNN/), and VS Code extension
- Dev/daily script install leaves behind:
channel = daily in global config
This causes the surviving install (e.g., WinGet stable 13.2.0) to resolve templates and packages from the wrong channel. For example, after removing a PR binary, the WinGet binary resolves aspire new to the PR SDK version and generates NuGet.config pointing to the local PR hive.
Reproduction (W35 scenario)
- Install stable via WinGet (13.2.0)
- Install PR build via
get-aspire-cli-pr.ps1 15573
- Remove the PR binary:
Remove-Item ~/.aspire/bin/aspire.exe
- WinGet binary takes over but:
aspire config get channel → pr-15573 (stale)
aspire new → resolves to PR SDK 13.3.0-pr.15573.g332b6688
- Generated
NuGet.config points to ~/.aspire/hives/pr-15573/packages
Proposal
Add an uninstall/cleanup mechanism that covers the full lifecycle. This could be:
aspire uninstall command — cleans up binary, PATH entry, channel config, hives, and optionally VS Code extension
--uninstall flag on install scripts — get-aspire-cli.ps1 --uninstall / get-aspire-cli-pr.ps1 --uninstall
- Automatic cleanup on reinstall — when the stable install script detects a PR channel/hive, offer to clean it up
At minimum, the cleanup should:
Current workaround
Users must manually:
aspire config set channel ""
Remove-Item -Recurse ~/.aspire/hives/pr-*
Context
Found during CLI acquisition playbook Run 5 (scenarios W33–W36).
Summary
When multiple Aspire CLI installation methods coexist (WinGet, release script, PR dogfood script), removing one install doesn't clean up its side effects. This leaves stale configuration that silently breaks the remaining installs.
Problem
All Aspire CLI binaries share the same
~/.aspire/config directory regardless of installation method. When a script or PR install is removed (by deleting the binary), the remaining install (e.g., WinGet) inherits stale config:channel = pr-NNNNNin global config, hive directory (~/.aspire/hives/pr-NNNNN/), and VS Code extensionchannel = dailyin global configThis causes the surviving install (e.g., WinGet stable 13.2.0) to resolve templates and packages from the wrong channel. For example, after removing a PR binary, the WinGet binary resolves
aspire newto the PR SDK version and generatesNuGet.configpointing to the local PR hive.Reproduction (W35 scenario)
get-aspire-cli-pr.ps1 15573Remove-Item ~/.aspire/bin/aspire.exeaspire config get channel→pr-15573(stale)aspire new→ resolves to PR SDK13.3.0-pr.15573.g332b6688NuGet.configpoints to~/.aspire/hives/pr-15573/packagesProposal
Add an uninstall/cleanup mechanism that covers the full lifecycle. This could be:
aspire uninstallcommand — cleans up binary, PATH entry, channel config, hives, and optionally VS Code extension--uninstallflag on install scripts —get-aspire-cli.ps1 --uninstall/get-aspire-cli-pr.ps1 --uninstallAt minimum, the cleanup should:
~/.aspire/bin/aspire.exe(script installs)~/.aspire/binfrom User PATHchannelfrom global config (~/.aspire/aspire.config.json)~/.aspire/hives/pr-*/)Current workaround
Users must manually:
Context
Found during CLI acquisition playbook Run 5 (scenarios W33–W36).