`aspire add` picker displays wrong version for C# AppHosts pinned to a non-default channel (pin ignored, installed version differs from displayed)

[radical]

What's broken

For a C# AppHost (*.csproj with <IsAspireHost>true</IsAspireHost>),
aspire add and aspire integration list ignore the channel pin in
aspire.config.json. The picker fans out to every available channel
(Implicit / Stable / Daily / Staging / hives) and dedupes by package id
with Implicit always winning over any Explicit channel. The result: for
any integration that's available from both the user's ambient
nuget.config (Implicit) and the project's pinned channel, the stable
version is displayed in the picker.

On aspire add <integration>, the project's nuget.config (which is
written with the matching channel's packageSource + packageSource Mapping) takes over and dotnet add package resolves the PR /
localhive version at restore time. The displayed version is therefore
different from the version that actually gets installed.

Polyglot AppHosts (TypeScript / Python / Go / Java / Rust) do NOT have
this bug: they honor aspire.config.json#channel and display the
pinned-channel version. So a user can see the asymmetry inside a single
install simply by switching the AppHost language.

Repro

Repro reproduces on the current main daily/dev build as well as on
PR #17105 — see "Reproduces on" below.

Setup a PR-acquired install:

./eng/scripts/get-aspire-cli-pr.sh 17105 \
    --install-path /tmp/aspire-issue-val --skip-extension --skip-path
CLI=/tmp/aspire-issue-val/dogfood/pr-17105/bin/aspire

# Two projects with the same channel pin — only the language differs.
mkdir -p /tmp/aspire-issue-val/cs-demo/cs.AppHost /tmp/aspire-issue-val/ts-demo

cat > /tmp/aspire-issue-val/cs-demo/cs.AppHost/cs.AppHost.csproj <<'EOF'
<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>net10.0</TargetFramework>
    <IsAspireHost>true</IsAspireHost>
  </PropertyGroup>
</Project>
EOF
cat > /tmp/aspire-issue-val/cs-demo/aspire.config.json <<'EOF'
{ "channel": "pr-17105" }
EOF

cat > /tmp/aspire-issue-val/ts-demo/apphost.ts <<'EOF'
// stub
EOF
cat > /tmp/aspire-issue-val/ts-demo/aspire.config.json <<'EOF'
{ "channel": "pr-17105" }
EOF

# What version of Redis does each project's picker show?
echo "=== C# AppHost ==="
$CLI integration list --apphost /tmp/aspire-issue-val/cs-demo/cs.AppHost/cs.AppHost.csproj \
    --format json | jq '.[] | select(.package == "Aspire.Hosting.Redis")'

echo "=== TypeScript AppHost ==="
$CLI integration list --apphost /tmp/aspire-issue-val/ts-demo/apphost.ts \
    --format json | jq '.[] | select(.package == "Aspire.Hosting.Redis")'

Expected

Both AppHosts honor aspire.config.json#channel. The picker displays
the same channel-pinned version that dotnet add package will actually
install. A C# AppHost pinned to pr-17105 displays
Aspire.Hosting.Redis 13.4.0-pr.17105.<sha>, not a stable version.

Actual

=== C# AppHost ===
{ "name": "redis", "package": "Aspire.Hosting.Redis", "version": "13.3.4" }

=== TypeScript AppHost ===
{ "name": "redis", "package": "Aspire.Hosting.Redis", "version": "13.4.0-pr.17105.g93e48e16" }

Same install, same hive, same channel pin in aspire.config.json —
different version displayed depending only on AppHost language. On
aspire add redis, the C# project resolves the PR version at restore
time anyway (via the nuget.config package-source-mapping written
during scaffolding), so the displayed 13.3.4 is a lie about what the
user actually ends up with.

Reproduces on

• PR feat(cli): aspire doctor lists every Aspire CLI install on the machine #17105 install (13.4.0-pr.17105.g93e48e16): C# returns 118 rows
  including stable Redis; polyglot returns 58 rows including PR Redis.
• Daily/dev install (13.4.0-preview.1.26269.7, installed via
  https://aka.ms/aspire/get/install.sh --quality dev): same shape.
  With a nonexistent pr-99999 pin in aspire.config.json, C# returns
  128 rows (pin completely ignored); polyglot returns 0 rows (pin
  honored, filters to nonexistent channel). The asymmetry is intrinsic
  to the code path, not the install route.

Why

src/Aspire.Cli/Commands/IntegrationPackageSearchService.cs:88-91:

if (project.LanguageId == KnownLanguageId.CSharp)
{
    return (ConfiguredChannel: null, ExitCode: null);
}

This short-circuit was written under the assumption that C# projects
express their channel via nuget.config rather than
aspire.config.json. But aspire add's picker is a discovery surface,
not a restore mechanism — the user needs to see the version that's
about to be installed. The two concerns ("which source does dotnet add package use?" vs. "which version does the picker display?") were
conflated.

The downstream dedup at SelectPreferredIntegrationPackage
(line 131-137) then prefers Implicit:

return packages
    .OrderByDescending(p => p.Channel.Type is PackageChannelType.Implicit)
    .ThenByDescending(p => SemVersion.Parse(p.Package.Version), …)
    .First();

So even when the PR hive contributes a higher semver, Implicit's lower
semver wins for any shared id.

Scope

Affects:

• aspire add interactive picker
• aspire integration list
• aspire integration search
• MCP list-integrations tool

…all only for C# AppHosts with a non-default aspire.config.json# channel pin. Polyglot AppHosts work correctly.

Does not affect:

• Restore-time resolution (the project's nuget.config correctly
  routes Aspire* to the hive via packageSourceMapping). The actual
  installed package is correct; only the picker's displayed version is
  wrong.
• Default-channel C# AppHosts (no other channel competes for dedup).

Possible directions

1. Honor aspire.config.json#channel for C# AppHosts too — read the
   pin and use it as the channel filter, same way polyglot does.
2. Add a per-row channel column to the picker so the user can see that
   the displayed version came from default while a pr-17105 row
   also exists at a different version.
3. Reverse the dedup preference so a configured-channel match beats
   Implicit when the project is pinned to that channel.

Notes

Related to #17225 (about which channel gets used during scaffolding) and
#17292 (about which packages are eligible for the picker after PR #17105
aligned hive-channel filtering with non-hive). This issue is about what
the picker displays for an already-pinned C# project.

Counterpart: #17295 — polyglot AppHosts have the opposite
problem (the pin is honored too strictly and removes all off-channel
integrations from the picker).

[joperezr]

🤖 Aspire triage pass — 2026-05-20 03:39 UTC

Area: area-cli, area-integrations
Kind: bug
Repro: yes-minimal — see the "Repro" section of the issue body (script reproducing on both PR #17105 install and daily/dev build)
Affected version(s): 13.4.0-pr.17105.g93e48e16, 13.4.0-preview.1.26269.7 (in-development 13.4; not present in shipped 13.3.x)
Severity: S3 — picker displays a misleading version for C# AppHosts pinned to a non-default channel; dotnet add still resolves the correct version, and unpinning is an available workaround

Urgency: 🟡 vNext — recommend milestone 13.4
Reason: bug is only observable in in-flight 13.4 preview/PR builds (not shipped 13.3.x), has a clean repro, cites the exact code path in src/Aspire.Cli/Commands/IntegrationPackageSearchService.cs, and is the counterpart of #17295 in the same channel-pinning family.

Suggested owner(s): @JamesNK (score: dominant area-cli contributor over the last 90 days — merged 70+ PRs in area-cli, including very recent ones #17260, #17251, #17231, #17198), backup @mitchdenny (recent area-cli merges #15423, #15075, #14568)
Evidence:

• JamesNK has merged the overwhelming majority of area-cli PRs in the last 90 days (e.g. Move InitCommand hardcoded strings to resource file for localization #17260, Improve ConsoleCancellationManager with process termination timeout #17251, Route error-context DisplayMessage calls to stderr in BaseCommand #17231, Use grid layout in DisplayMessage/DisplayError for better text wrapping #17198, Fix flaky NewCommandChannelResolutionTests by isolating home directory #17180, Fix CLI cancellation disposal race on shutdown #17179, CLI: Print app host CLI log path when connected to a running app host #17168, Improve version log messages in CLI, AppHost and dashboard #17163, Handle canceled backchannel streams #17114, Refactor CLI commands to return CommandResult and centralize cancellation handling #17005)
• mitchdenny has merged area-cli PRs Fix config discovery to search from apphost directory and add aspire.config.json to .NET templates #15423, Remove mature feature flags that no longer need toggles #15075, Fix CopilotCliRunner version parsing for 'GitHub Copilot CLI X.X.X' format #14568, Fix TryGetResourceToolMap cache miss causing perpetual tools/list refresh loop #14539
• Issue author @radical is excluded as the reporter
• CODEOWNERS not consulted (the cited file lives under src/Aspire.Cli/, broadly owned by the CLI team)

Confidence: medium
Needs human?: no — but a human should confirm whether this should ride alongside the fix for #17295 (same family) and whether PR #17105 already addresses one of the two.

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