Support separate container and product versions for stable CLI installs on our CLI scripts

[joperezr]

Description

This PR updates the get-aspire-cli.ps1 and get-aspire-cli.sh scripts to support installing stable versions of the Aspire CLI when the container path version differs from the product version.

Background

When stabilizing builds, the product version becomes stable (e.g., 9.5.0), but the container name/path in blob storage remains unstable (e.g., 9.5.0-preview.1.25522.3). This is done intentionally to avoid clashes if the stable build needs to be re-spun, as each build gets a unique container path based on its build number.

Changes

Both scripts now accept separate version parameters:

• -Version / --version: The container path version (unstable) used in the blob storage URL path
• -ProductVersion / --product-version: The actual CLI executable product version (stable) used in the filename

When ProductVersion / --product-version is not specified, it defaults to the value of Version / --version, maintaining backward compatibility for unstable/preview builds where both versions are identical.

Examples

Unstable/preview builds (no change in behavior):

.\get-aspire-cli.ps1 -Version "9.5.0-preview.1.25366.3"

./get-aspire-cli.sh --version "9.5.0-preview.1.25366.3"

Stable builds (new capability):

.\get-aspire-cli.ps1 -Version "9.5.0-preview.1.25522.3" -ProductVersion "9.5.0"

./get-aspire-cli.sh --version "9.5.0-preview.1.25522.3" --product-version "9.5.0"

This results in URLs like:

https://ci.dot.net/public/aspire/9.5.0-preview.1.25522.3/aspire-cli-win-x64-9.5.0.zip

Where the path uses the unstable container version, but the filename contains the stable product version.

Checklist

• Is this feature complete?
  • Yes. Ready to ship.
• Are you including unit tests for the changes and scenario tests if relevant?
  • No
• Did you add public API?
  • No
• Does the change make any security assumptions or guarantees?
  • No
• Does the change require an update in our Aspire docs?
  • Yes
    • Link to aspire-docs issue (consider using one of the following templates):
      • New (or update) doc-idea template
      • New breaking-change template
      • New diagnostic template

[github-actions]

🚀 Dogfood this PR with:

⚠️ WARNING: Do not do this without first carefully reviewing the code of this PR to satisfy yourself it is safe.

curl -fsSL https://raw.githubusercontent.com/dotnet/aspire/main/eng/scripts/get-aspire-cli-pr.sh | bash -s -- 13048

Or

• Run remotely in PowerShell:

iex "& { $(irm https://raw.githubusercontent.com/dotnet/aspire/main/eng/scripts/get-aspire-cli-pr.ps1) } 13048"

[Copilot]

Pull Request Overview

This PR adds support for installing stable versions of the Aspire CLI when the container path version differs from the product version. This addresses a scenario where stable builds (e.g., 9.5.0) are stored in blob storage under unstable container paths (e.g., 9.5.0-preview.1.25522.3) to avoid naming conflicts during build respins.

Key changes:

• Adds new --product-version / -ProductVersion parameter to both CLI installation scripts
• Updates URL construction logic to use container version in path and product version in filename
• Maintains backward compatibility by defaulting product version to container version when not specified

Reviewed Changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File	Description
eng/scripts/get-aspire-cli.sh	Adds --product-version parameter, updates construct_aspire_cli_url() function to accept and use product version in filename generation, updates help text and examples
eng/scripts/get-aspire-cli.ps1	Adds -ProductVersion parameter, updates Get-AspireCliUrl() function to accept and use product version in filename generation, updates help text and examples

[radical]

@joperezr Can you help me understand how this would get used? Would it only be when we re-spin a stable version? How would users get to the know the "latest unstable version" to use?

[joperezr]

@joperezr Can you help me understand how this would get used? Would it only be when we re-spin a stable version? How would users get to the know the "latest unstable version" to use?

Today we always produce blobs like this, meaning the container name is always unstable in order avoid issues in the case we need to re-spin a stable version to avoid clashes. To your point, it is not straight forward to know which prerelease version to use when you want to install an older stable version, and for the most part that's okay because most people will want to always install the latest from each channel anyway which uses aka.ms links to abstract these versions from them, but there will be cases where people want/need to get an older CLI, and these changes just allow them to be able to get them.

For instance, let's say for some reason someone needs to get the 9.5.2 CLI for some reason, since we've shipped 13.0 now, the GA channel will just get them 13.0 instead, so they need to pass in version to get 9.5.2, but if they try to do iex "& { $(irm https://aspire.dev/install.ps1) } -Version 9.5.2" this will fail with the following error:

Downloading from: https://ci.dot.net/public/aspire/9.5.2/aspire-cli-win-x64-9.5.2.zip
Write-Error:
Line |
1078 |          Write-Message "Error: $($_.Exception.Message)" -Level Error
     |          ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     | Error: Failed to download https://ci.dot.net/public/aspire/9.5.2/aspire-cli-win-x64-9.5.2.zip - Response status code does not indicate success: 404 (The specified blob does not exist.)

This is because the url it is trying to fetch is https://ci.dot.net/public/aspire/9.5.2/aspire-cli-win-x64-9.5.2.zip, when the real one actually lives in https://ci.dot.net/public/aspire/9.5.2-preview.1.25522.3/aspire-cli-win-x64-9.5.2.zip instead. With the changes of this PR, people will now be able to say iex "& { $(irm https://aspire.dev/install.ps1) } -Version 9.5.2-preview.1.25522.3 -ProductVersion 9.5.2" and it will install successfully.