Fix aspire update --self to install to current CLI location #13722
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Previously, `aspire update --self` always installed to `$HOME/.aspire/bin` regardless of where the CLI was originally installed. This caused issues when the CLI was installed to a custom path like `/usr/local/bin` using `--install-path`. Now the command installs the update to the same directory as the currently running CLI executable, determined via `Environment.ProcessPath`. If the update fails due to insufficient permissions (e.g., writing to a protected directory like `/usr/local/bin`), a helpful error message is displayed advising the user to run with elevated permissions. Fixes dotnet#13140
Contributor
|
🚀 Dogfood this PR with:
curl -fsSL https://raw.githubusercontent.com/dotnet/aspire/main/eng/scripts/get-aspire-cli-pr.sh | bash -s -- 13722Or
iex "& { $(irm https://raw.githubusercontent.com/dotnet/aspire/main/eng/scripts/get-aspire-cli-pr.ps1) } 13722" |
dotnet-policy-service
bot
added
the
community-contribution
Contributor
There was a problem hiding this comment.
Pull request overview
This PR fixes a bug where aspire update --self always installed to $HOME/.aspire/bin regardless of the CLI's original installation location. The fix makes the command install updates to the same directory as the currently running CLI executable, determined via Environment.ProcessPath. It also adds proper error handling for permission issues when updating to protected directories like /usr/local/bin.
Key Changes
- Changed installation directory detection from hardcoded
$HOME/.aspire/binto the directory of the currently running CLI executable - Added
UnauthorizedAccessExceptionhandling with a helpful error message advising users to run with elevated permissions - Added new localized resource string
NoWritePermissionToInstallDirectoryacross all supported languages
Reviewed changes
Copilot reviewed 15 out of 16 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
| src/Aspire.Cli/Commands/UpdateCommand.cs | Updated ExtractAndUpdateAsync to use Environment.ProcessPath instead of home directory, added exception handling for permission errors |
| src/Aspire.Cli/Resources/UpdateCommandStrings.resx | Added new error message resource for permission issues |
| src/Aspire.Cli/Resources/UpdateCommandStrings.Designer.cs | Added resource accessor property for the new error message |
| src/Aspire.Cli/Resources/xlf/*.xlf | Added new untranslated resource strings to all 13 localization files (cs, de, es, fr, it, ja, ko, pl, pt-BR, ru, tr, zh-Hans, zh-Hant) |
Files not reviewed (1)
- src/Aspire.Cli/Resources/UpdateCommandStrings.Designer.cs: Language not supported
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes #13140
Description
Previously,
aspire update --selfalways installed to$HOME/.aspire/binregardless of where the CLI was originally installed. This caused issues when the CLI was installed to a custom path like/usr/local/binusing--install-path.Now the command installs the update to the same directory as the currently running CLI executable, determined via
Environment.ProcessPath. If the update fails due to insufficient permissions (e.g., writing to a protected directory like/usr/local/bin), a helpful error message is displayed advising the user to run with elevated permissions.The changes were tested manually with:
Permission error handling was tested on Linux with:
Checklist
UnauthorizedAccessExceptionpath requires real filesystem permission restrictions that are difficult to reliably trigger in unit tests without mocking infrastructure. The existing 21 tests continue to pass.<remarks />and<code />elements on your triple slash comments?doc-ideatemplatebreaking-changetemplatediagnostictemplate~/.aspire/bin).