[Feature]: CommunityToolkit.Aspire.Hosting.Floci — Cosmos DB connection string helper for AddFlociAzure

[thomhurst]

Package

CommunityToolkit.Aspire.Hosting.Floci

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

AddFlociAzure(...) today models a single HTTP endpoint (:4577) and WithReference(azure) injects ConnectionStrings__{name} (the base URL) plus a ready-to-use AZURE_STORAGE_CONNECTION_STRING for the Blob/Queue/Table SDKs.

There's no equivalent for Cosmos DB, even though floci-az emulates the Cosmos SQL/NoSQL API on the same :4577 endpoint. A .NET app that wants to talk to floci's Cosmos has to hand-build the connection string itself — combining the emulator endpoint (which is dynamic under --isolated/random ports), the -cosmos account path suffix, and the well-known Cosmos emulator key — instead of just calling AddAzureCosmosClient("cosmos").

This is the one missing piece for a project to consume floci-az Cosmos through the standard Aspire connection-string flow.

Describe the solution you'd like

A WithCosmosReference helper on the Floci Azure resource that injects a Cosmos connection string under a caller-chosen connection name, mirroring how the storage connection string is injected today:

var azure = builder.AddFlociAzure("floci-az");

builder.AddProject<Projects.Api>("api")
    .WithCosmosReference(azure)          // connectionName defaults to "cosmos"
    .WaitFor(azure);

App side is then the standard Aspire flow:

builder.AddAzureCosmosClient("cosmos");

Injected env var (endpoint resolved by Aspire, so it tracks random/isolated ports):

ConnectionStrings__cosmos = AccountEndpoint={scheme}://{host}:{port}/devstoreaccount1-cosmos/;AccountKey=C2y6yDjf5/R+ob0N8A7Cgv30VRDJIWEHLM+4QDU5DE2nQ9nDuVTqobD4b8mGGyPMbIZnqyMsEcaGQy67XIw/Jw==;

Proposed signature (parallels the existing withFlociAzureReference, with its own TS binding since the generated bindings have no overload resolution):

[AspireExport("withFlociAzureCosmosReference")]
public static IResourceBuilder<TDestination> WithCosmosReference<TDestination>(
    this IResourceBuilder<TDestination> builder,
    IResourceBuilder<FlociAzureContainerResource> floci,
    string connectionName = "cosmos",
    string? accountName = null)   // defaults to devstoreaccount1
    where TDestination : IResourceWithEnvironment;

Uses the well-known Cosmos emulator key (C2y6…), distinct from the Azurite storage key already used for AZURE_STORAGE_CONNECTION_STRING. The endpoint is built from the resource's existing Scheme/Host/Port reference expressions, so it resolves correctly for both a project (localhost:{hostPort}) and a sibling container.

Scope / non-goals

• Just the connection-string plumbing. Client-side quirks of talking to the floci Cosmos emulator over HTTP from the .NET SDK (Gateway mode, HTTP/1.1 pinning, dev-cert bypass) are the app's concern, as with the existing storage helper.
• Service Bus is intentionally out of scope here — its AMQP data plane runs on a floci-launched Artemis sidecar whose port isn't modelled as an Aspire endpoint (only the :4577 management plane is), so a SB connection-string helper needs an endpoint-modelling decision on the floci-az side first. Cosmos has no such issue: it's served on the endpoint already exposed.

Additional context

I'm a floci-az contributor and have a working implementation ready; happy to open the PR against this issue.

Are you willing to contribute a PR?

• Yes