[Feature] support third-party hosting integrations in aspire add/update via package metadata

[jomaxso]

Is your feature request related to a problem? Please describe the problem.

I am trying to use aspire add and aspire update with third-party hosting integration packages, but the CLI currently has no explicit package-metadata-based way to discover or recognize them.

PR #16845 improved this area significantly by introducing aspire integration list and aspire integration search as the read-only discovery surface. However, discovery still appears to be limited by the current built-in integration matching rules, and there is still no clear package-level opt-in model for third-party hosting integrations.

In practice this means:

• third-party hosting integrations are harder to discover unless they happen to match the current naming assumptions
• aspire add cannot provide a consistent first-class workflow for those packages
• aspire update has no clear package-level signal for whether a third-party package should participate in Aspire integration update flows

This is especially relevant for polyglot app hosts, where CLI-specific bookkeeping should ideally not require changes to apphost.ts or other language-specific source files.

Describe the solution you'd like

Introduce an explicit package-level opt-in for third-party hosting integrations via NuGet package metadata.

For example, define a well-known NuGet tag such as:

<PackageTags>aspire-hosting</PackageTags>

Packages that include this tag should be treated as Aspire hosting integrations by the CLI.

Expected behavior

Discovery / aspire add

Packages tagged with aspire-hosting should be discoverable in:

• aspire integration list
• aspire integration search
• aspire add

This should be additive to the existing first-party and CommunityToolkit behavior, not a replacement for it.

aspire update

aspire update should also be able to account for these opted-in packages when determining which hosting integrations in the current project should be updated.

Output / UX idea

It would also be helpful if the CLI output could distinguish between:

• Aspire-native integrations
• CommunityToolkit integrations
• third-party integrations

I do not have a strong opinion on the exact UX shape, but some kind of grouping or labeling in CLI output would make discovery much clearer.

For example, aspire integration list / aspire integration search could:

• group results by source, or
• display a label such as Built-in, CommunityToolkit, or Third-party

This would help users understand what is officially part of Aspire versus what comes from the wider ecosystem.

Important constraints

The CLI should not require additional CLI-specific markers in source or project files solely for discovery/update support.

In particular, this should avoid requiring:

• extra markers in apphost.ts
• extra markers in apphost.cs
• extra PackageReference metadata written only for CLI bookkeeping

The package metadata should be the primary opt-in signal.

aspire.config.json as project-local state

If project-local state is needed, especially for polyglot app hosts, aspire.config.json seems like a better place to store that than language-specific source or project files.

For example, the CLI could optionally persist which integrations are part of the current app in aspire.config.json, while still using package metadata as the source of truth for opt-in.

That would help keep polyglot scenarios clean while still giving aspire update enough project-local context.

Prior art / related work

PR #16845 already established aspire integration list and aspire integration search as the non-interactive discovery surface. This proposal builds on top of that work by extending discovery and update behavior to support explicit third-party hosting integration opt-in via package metadata.

Additional context

A concrete motivation is support for third-party packages such as:

• Scalar.Aspire
• DevProxy.Hosting

Those packages may represent valid hosting integrations, but they currently do not fit naturally into the existing CLI discovery/update flow.

It may also be worth documenting the recommended NuGet metadata convention for third-party hosting integrations if the team agrees on a canonical tag such as aspire-hosting.

Open design questions:

• Should aspire.config.json be the preferred project-local place to persist integration references for update scenarios, especially for polyglot app hosts?
• Should discovery output include explicit grouping or labels to distinguish built-in Aspire integrations from third-party ones?

[IEvangelist]

+1 from a third-party package author. I maintain a handful of hosting packages (none of them official or in the CommunityToolkit), and aspire add doesn't really have a path for them today.

A couple of concrete things I'd add to the discussion:

• Even fully qualifying the package ID doesn't work. Today the CLI hardcodes its NuGet search to Aspire.Hosting, so anything that doesn't happen to contain that string in its ID/metadata is invisible — aspire add My.Org.Hosting.Foo returns nothing, even though My.Org.Hosting.Foo is a real, installable hosting package. There's no escape hatch.
• An explicit override would help in the meantime — something like aspire add <package-id> --allow-any (or honoring --source as a "trust me" signal) so authors and users aren't blocked while a tag-based opt-in like the one you proposed gets designed.

Otherwise I'm fully aligned with what you've outlined: a PackageTags opt-in (e.g. aspire-hosting), additive to first-party + CommunityToolkit, with grouped/labeled output so users can see where each integration is coming from. The aspire.config.json direction for polyglot bookkeeping also makes sense to me.

[jomaxso]

we could target something like that:

[jomaxso]

I've added a pr #16882 to show my ideas.

[davidfowl]

3rd party integrations need to be an opt-in. We can make it a top-level config as well as a flag but they shouldnt show up in the curated set by default. We also need to warn people and make it really clear that these are not owned by the aspire team which means they may be a varying level of quality (and also dont file bugs on this repo 😄).

I'd also love to open the door to adding extra 3rd party feeds (which you can do manually with nuget.config today).

cc @DamianEdwards @eerhardt

[jomaxso]

@davidfowl I updated #16882 based on your feedback.

The current shape makes third-party integrations opt-in:

• default discovery remains official/curated only
• users can opt in per command via --discovery-scope all or third-party
• project config can control third-party discovery with off, ask, or on
• config can also list extra feeds/package IDs so private or non-nuget.org packages have a path
• interactive aspire add can ask whether to include third-party packages
• adding a third-party package shows an explicit warning/confirmation, defaulting to No

The output also distinguishes official, Community Toolkit, and third-party groups, so the broader ecosystem does not show up as part of the curated Aspire set. The package metadata tag remains the opt-in signal; we are not writing CLI-specific markers into AppHost source files.

I also added a short demo video on the PR here: #16882 (comment)

[jomaxso]

One additional thought on the discovery mechanism:

Instead of using a very specific tag such as aspire-hosting as the initial discovery signal, we could consider discovering candidates from the broader aspire NuGet tag and then perform a second validation step against the package metadata/dependency graph.

For example, after finding packages tagged with aspire, the CLI could inspect the package dependencies and only treat the package as a hosting integration if it references Aspire.Hosting.

That might make discovery less dependent on package authors knowing and applying a new specialized tag, while still filtering out most unrelated Aspire packages. It would also align the classification more closely with the actual package shape.

That said, this would not solve the private-feed limitation of NuGet tag search itself. It would only make the tag convention broader and use dependency metadata as the stronger hosting-integration signal.