Track Orleans provider integration and end-to-end testing with Aspire #10784

Goal

Provide a complete, tested Orleans + Aspire experience for every backend which has both:

1. an Orleans provider in this repository; and
2. a first-party Aspire hosting integration maintained by Microsoft or the service owner.

Each supported pairing should produce valid Orleans configuration from an Aspire AppHost and have tests which prove both configuration activation and live provider behavior.

Why

Aspire.Hosting.Orleans can model clustering, grain storage, reminders, streaming, and grain directories, but support is only reliable when the Orleans provider assembly registers an IProviderBuilder for the provider type and correctly consumes the configuration emitted by the Aspire resource reference.

The repository currently has many provider builders but very little DistributedApplicationTestingBuilder coverage. Some capabilities have no builder, some resource types need explicit provider-type overrides, and grain journaling is not currently modeled by Aspire.Hosting.Orleans. Unit tests which configure a provider directly do not prove that the AppHost resource model, generated environment, keyed client registration, configuration binding, and Orleans startup work together.

PR #9328 and issue #9244 establish the Event Hubs pattern. Aspire tests should be added to each provider's existing test project rather than creating separate *.Aspire.Tests projects.

Scope and inventory

The initial scope uses first-party Aspire integrations from microsoft/aspire plus the AWS-maintained Aspire.Hosting.AWS integration. Community-only/manual-container integrations are listed separately below.

Official integration references:

• Aspire integration source: https://github.com/microsoft/aspire/tree/main/src
• Aspire Orleans integration: https://aspire.dev/integrations/frameworks/orleans/
• AWS Aspire integration: https://github.com/aws/integrations-on-dotnet-aspire-for-aws

Standard implementation contract

For every row:

• Register stable Orleans provider aliases using RegisterProvider for every applicable capability and host role (silo/client).
• Implement IProviderBuilder<ISiloBuilder> and, where applicable, IProviderBuilder<IClientBuilder>.
• Accept the configuration shape emitted by the Aspire resource, including ServiceKey, ConnectionName, direct connection values, and resource-specific connection properties.
• Prefer keyed Aspire clients when the Orleans provider uses the service SDK directly; use injected connection strings for ADO.NET providers.
• Support WithOrleansProviderType(...) when Aspire cannot infer the Orleans provider name from the resource type.
• Validate missing, ambiguous, or incompatible configuration during startup with actionable errors.
• Preserve secret redaction and workload/managed identity behavior.
• Document provider-specific topology and lifecycle ownership: which resources Aspire provisions, which resources Orleans creates, and which must exist before startup.
• Update the GitHub Pages Aspire provider matrix and add compiled AppHost/silo/client examples.

Standard test contract

Place Aspire tests in the existing provider test project. Do not add one Aspire-only test project per provider.

Each provider should have:

1. App-model tests using DistributedApplicationTestingBuilder:
   • create the backing Aspire resource and Orleans resource;
   • connect them using WithClustering, WithGrainStorage, WithReminders, WithStreaming, or WithGrainDirectory;
   • evaluate generated environment/configuration;
   • build a silo/client host from that configuration;
   • verify provider activation and bound options;
   • cover provider-type inference and explicit WithOrleansProviderType overrides;
   • cover invalid/incomplete configuration.
2. Live integration tests using the provider's existing emulator/container/CI service:
   • start a cluster from Aspire-generated configuration;
   • exercise the provider's real capability (membership, state round trip, reminders, directory lookup, stream publish/consume/checkpoint, or journaling recovery);
   • verify restart/recovery behavior where that is a core provider guarantee;
   • run under the provider's existing GitHub Actions job and traits.
3. Framework coverage:
   • keep Aspire app-model tests on the framework required by the current Aspire packages;
   • exercise the resulting Orleans provider behavior on every Orleans target framework supported by the existing provider CI job (net8.0 and net10.0 today) where package constraints permit it.

Cross-repository Aspire gaps

Open or link upstream Aspire issues when the Orleans integration cannot represent a capability correctly. Known examples:

• WithStreaming and other provider operations currently require IResourceWithConnectionString; AWS CDK constructs expose structured outputs instead.
• Aspire.Hosting.Orleans does not currently expose a grain-journaling operation.
• Some services represent one physical resource while an Orleans provider owns a partitioned resource set.
• ADO.NET resource types do not infer the AdoNet provider name or invariant automatically.

Excluded from the initial matrix

Orleans also supports Cassandra, Consul, ZooKeeper, and Google Cloud Firestore. They do not currently have first-party Aspire hosting integrations in microsoft/aspire or a service-owner Aspire integration equivalent to Aspire.Hosting.AWS. Track them here only after adopting an official integration contract; community containers can still be documented as manual AppHost resources.

SQLite is also excluded because it is an embedded/local database rather than a distributed Aspire backing-service resource.

Completion checklist

• Azure Storage capabilities have app-model and live Aspire tests.
• Cosmos DB clustering, storage, and reminders have complete provider builders and Aspire tests.
• Redis/Azure Redis capabilities have app-model and live Aspire tests.
• ADO.NET support is proven for SQL Server, PostgreSQL, MySQL/MariaDB, and Oracle; ADO.NET streaming has a provider builder.
• Event Hubs work in Missing EventHubs provider for Aspire / IConfiguration #9244 / feat(streaming): add Event Hubs Aspire support #9328 is complete and tests are in the existing Event Hubs test project.
• NATS streaming has provider builders and Aspire tests.
• DynamoDB clustering/storage/reminders have AWS Aspire tests.
• SQS work in Add Orleans SQS integration for Aspire with end-to-end tests #10783 is complete.
• Kinesis streaming has AWS Aspire integration and tests.
• Grain journaling resource modeling is implemented upstream or has a documented, tested explicit configuration path.
• The GitHub Pages Aspire integration matrix reflects every verified pairing and links to provider-specific guidance.