respect central package management when adding aspire integration to AppHost

[Muckenbatscher]

Description

Previously when running aspire add [integration-name] the PackageReference element with a Version attribute would be added to the AppHost.csproj directly.
When Central Package Management is in place this will lead to a build error NU1008.

The PackageReference is added to the AppHost.csproj directly because the --no-restore flag is passed to the dotnet CLI when no source is explicitly specified for aspire add. This effectively tells the dotnet CLI to skip the validation that is required for adding the PackageVersion to the Directory.Packages.props.

So if no source is explicitly specified to the aspire add command pass the one, where the integration NuGet package was found in (for most cases this will be the nuget.org source).

Fixes #13241

Checklist

• Is this feature complete?
  • Yes. Ready to ship.
  • No. Follow-up changes expected.
• Are you including unit tests for the changes and scenario tests if relevant?
  • Yes
  • No
• Did you add public API?
  • Yes
    • If yes, did you have an API Review for it?
      • Yes
      • No
    • Did you add <remarks /> and <code /> elements on your triple slash comments?
      • Yes
      • No
  • No
• Does the change make any security assumptions or guarantees?
  • Yes
    • If yes, have you done a threat model and had a security review?
      • Yes
      • No
  • No
• Does the change require an update in our Aspire docs?
  • Yes
    • Link to aspire.dev issue:
      • New issue
  • No

[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 -- 14875

Or

• Run remotely in PowerShell:

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

[davidfowl]

@Muckenbatscher can you open ths against the release/13.2 branch?

[Muckenbatscher]

@dotnet-policy-service agree

[maddymontaquila]

THANK you - this is a great contrib!! @mitchdenny lets get this reviewed + merged for 13.2!

[Muckenbatscher]

The first approach was flawed.
Providing the --source argument made the dotnet CLI use only that source for restoring all packages.

This would fail for packages that have (transitive) dependencies on other packages that are only available in a different source.

[JamesNK]

I tested locally and it works. I'll see if I can fix conflicts and get tests working.

[JamesNK]

Primary finding

StartStopTests.AddPackageWhileAppHostRunningDetached is failing due to package channel/version mismatch in non-interactive aspire add, not due to detach/stop behavior.

• In AddCommand, when hives exist, package discovery includes multiple channels (implicit, stable, daily, PR hives): src/Aspire.Cli/Commands/AddCommand.cs.
• In non-interactive mode, version selection previously chose the highest semver across all discovered channels.
• During the failing run, this selected Aspire.Hosting.MongoDB >= 13.3.0-preview..., but restore used PR hive feed state where only 13.2.0-pr.14875... existed, producing NU1102.
• The test then timed out waiting for success text because install already failed.

Analysis of the fix

Implemented fix in src/Aspire.Cli/Commands/AddCommand.cs:

• Non-interactive selection now prefers PackageChannelType.Implicit first, then picks the highest version within that preferred channel.
• This keeps non-interactive aspire add aligned with the project’s default/implicit feed context and avoids cross-channel highest-version drift when hives are present.

Regression coverage added

• New unit test: AddCommand_WithHives_PrefersImplicitChannelVersionInNonInteractiveMode
• File: tests/Aspire.Cli.Tests/Commands/AddCommandTests.cs
• Verifies that with hives present and both implicit/explicit versions available, non-interactive add chooses the implicit-channel version.

Result

• Targeted unit tests for AddCommandTests pass locally.
• This addresses the root cause behind the CI failure pattern (NU1102 -> timeout waiting for success message).

[JamesNK]

Details for commit 5065403dff

This commit contains the targeted fix for the failing E2E scenario by changing non-interactive package version selection behavior in aspire add when hives/channels are present.

What changed

• src/Aspire.Cli/Commands/AddCommand.cs
  • Updated non-interactive version ordering in GetPackageByInteractiveFlow(...):
    • Before: selected highest semver across all channels.
    • After: prefers PackageChannelType.Implicit first, then highest semver within that preference.

Why this matters

• The failure log showed aspire add mongodb --non-interactive selecting a higher preview version (13.3.0-preview...) while the PR hive only contained 13.2.0-pr..., causing restore failure (NU1102) and then timeout waiting for success output.
• Preferring the implicit channel in non-interactive mode keeps selection aligned with the project/default feed context and avoids cross-channel version drift.

Test coverage added in same commit

• tests/Aspire.Cli.Tests/Commands/AddCommandTests.cs
  • New test: AddCommand_WithHives_PrefersImplicitChannelVersionInNonInteractiveMode
  • Verifies that with both implicit and explicit channel versions available, non-interactive add chooses the implicit-channel version (the one compatible with the local hive context).

[davidfowl]

@Muckenbatscher Thanks for this PR, it's a really impactful one!