aspire update should not add nuget.org/channel feeds when a custom (mirrored) nuget.config already exists #19765

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

aspire update currently assumes every project should end up with the "known channel" NuGet feeds (e.g. api.nuget.org, the dnceng dotnetN feed, etc.) configured in nuget.config, and will offer to add them even when the project intentionally uses its own internal/mirrored feed(s) and nothing else.

This breaks first-party and enterprise scenarios that rely on feed mirroring (e.g. HashR-based repo clones), where nuget.config is deliberately scoped to a single internal feed. Running aspire update on such a repo offers to add https://api.nuget.org/v3/index.json (and a * wildcard package source mapping) back in, even though nuget.org was never present and the only configured feed is the internal mirror.

Expected Behavior

Discussed in the linked Teams thread, the agreed-upon direction is:

1. Before making any changes, run dotnet nuget list source (or equivalent) and check whether any of the "known channel" feeds (including api.nuget.org) are already present in nuget.config.
2. If none of the known channel feeds are present, but the config is not empty (i.e. other feed(s) already exist), treat this as a "channel-less" / custom-feed scenario:
   • Do not add api.nuget.org, the channel feed, or any wildcard package source mapping.
   • Leave the user's nuget.config untouched and rely on whatever feeds/mappings they've already configured to resolve the Aspire packages.
3. Only fall back to the current "add known channel feeds" behavior when nuget.config has no feeds configured at all (the genuine zero-feed/new-project case).

In short: the concept of "channels" should be considered incompatible with an existing custom nuget.config; if the user already has one, aspire update should not try to reconcile it with channel feeds at all.

Steps To Reproduce

1. Clone a repo that uses NuGet feed mirroring, with nuget.config scoped to a single internal feed (no api.nuget.org, no dnceng feeds).
2. Run aspire update.
3. Observe that the CLI offers to add https://api.nuget.org/v3/index.json (and a * package source mapping) even though it was never present, alongside the existing internal feed.

Exceptions (if any)

No response

Aspire doctor output

No response

Anything else?

Related discussion happened in a Microsoft Teams thread between Damian Edwards, Mitch Denny, David Fowler, and Jose Perez Rodriguez. Related issues:

• aspire update shoudl never override existing wildcard package source mapping #19192 — aspire update should never override existing wildcard package source mapping (same root cause: re-adding nuget.org/wildcard mapping unconditionally)
• nuget.config breaks Nuget packages from private repositories #16946 — nuget.config breaks NuGet packages from private repositories (same root cause: CLI-generated nuget.config overrides private/internal feed resolution)
• Staging TypeScript AppHost integration restore adds DARC feed without package source mappings #17629 — Staging TypeScript AppHost integration restore adds DARC feed without package source mappings (related: unconditional feed addition during restore)

Created from a Microsoft Teams conversation.