Staging build of CLI bakes channel as `stable`, causing `aspire init` to drop nuget.config without staging feed (resolves wrong Aspire package versions)

[mitchdenny]

Summary

The 13.4 staging build of the Aspire CLI is baking AspireCliChannel=stable into the binary instead of staging. As a result, aspire init drops a nuget.config whose only package source is https://api.nuget.org/v3/index.json — with no mapping for Aspire.* packages to the staging feed.

Downstream effects:

• aspire add yarp resolves the YARP integration to 13.3.5 (the last public release) instead of 13.4.
• The dropped apphost.cs pins #:sdk Aspire.AppHost.Sdk@13.4.0+<sha> (the staging SHA), which cannot be resolved from nuget.org at all, so aspire add ultimately fails with Unable to find package Aspire.AppHost.Sdk with version (= 13.4.0).

This blocks any meaningful dogfooding of the 13.4 staging CLI.

Repro

With the 13.4 staging CLI installed (13.4.0+0f51445275cc5bfd7d209aef7453d47673676bb7):

mkdir foo && cd foo
aspire init   # select C#
aspire add yarp

Observed:

• Generated nuget.config (no staging feed, no Aspire.* mapping):

<configuration>
  <packageSources>
    <clear />
    <add key="https://api.nuget.org/v3/index.json" value="https://api.nuget.org/v3/index.json" />
  </packageSources>
  <packageSourceMapping>
    <packageSource key="https://api.nuget.org/v3/index.json">
      <package pattern="*" />
    </packageSource>
  </packageSourceMapping>
</configuration>

• aspire add yarp fails with:

Unable to find package Aspire.AppHost.Sdk with version (= 13.4.0)
  - Found 31 version(s) in https://api.nuget.org/v3/index.json [ Nearest version: 13.3.5 ]

• aspire doctor confirms the CLI self-identifies as channel: stable:

│ /Users/.../aspire | 13.4.0+0f51445275... | stable | (unknown) | active │

Root cause

In eng/pipelines/templates/build_sign_native.yml the channel-compute condition order is:

if ($reason -eq 'PullRequest') {
  $channel = "pr-$prNumber"
} elseif ($versionKind -eq 'release') {
  $channel = 'stable'
} elseif ($sourceBranch -match '^refs/heads/(release|internal/release)/') {
  $channel = 'staging'
} else {
  $channel = 'daily'
}

A 13.4 staging build runs from a release/13.4 branch with StabilizePackageVersion=true, which sets DotNetFinalVersionKind=release (see eng/Versions.props). The versionKind == 'release' arm fires first and bakes stable, even though the build is a release-branch staging build.

When aspire init then calls TemplateNuGetConfigService.CreateOrUpdateNuGetConfigWithoutPromptAsync(channelName: _executionContext.IdentityChannel, ...), it looks up the stable channel — which has no explicit feed mapping — and falls through to a nuget.org-only config.

Fix

Reorder the conditions so the release-branch check runs before the versionKind == release check. Release-branch builds are always staging artifacts (they don't go directly to nuget.org); only release-shaped builds from non-release branches (effectively none in practice) should bake stable.

if ($reason -eq 'PullRequest') {
  $channel = "pr-$prNumber"
} elseif ($sourceBranch -match '^refs/heads/(release|internal/release)/') {
  $channel = 'staging'
} elseif ($versionKind -eq 'release') {
  $channel = 'stable'
} else {
  $channel = 'daily'
}

Impact / Priority

Urgent for 13.4. This breaks the staging CLI experience end-to-end — every customer who tries the 13.4 staging build via aspire init + aspire add will hit it. Without the fix, dogfooding 13.4 requires hand-authoring a nuget.config with the staging feed.