Surface Deveel Events publish channels as .NET Aspire resources, enabling dashboard visibility, structured telemetry, and one-line broker provisioning in the Aspire AppHost for the local development inner loop.
The problem today: Teams using .NET Aspire as their local orchestration platform must configure Deveel Events channels manually and separately from their Aspire resource graph. There is no Aspire component for the framework, so published events do not appear in the Aspire dashboard, channel health is not surfaced as a resource status, and developers must provision broker containers (RabbitMQ, Azure Service Bus emulator) without the convenience of Aspire's built-in resource integrations.
What we will build: A Deveel.Events.Publisher.Aspire package split into two assemblies following the standard Aspire pattern:
- AppHost component (
Deveel.Events.Publisher.Aspire.Hosting): Provides AddEventPublisher() and WithRabbitMqChannel() / WithAzureServiceBusChannel() / etc. extension methods on IDistributedApplicationBuilder that wire the framework's channel resources into the Aspire resource graph, configure connection strings, and automatically provision the matching Aspire container resources (e.g., AddRabbitMQ(), AddAzureServiceBus()) when running locally.
- Service component (
Deveel.Events.Publisher.Aspire.Client): Provides AddEventPublisherFromAspire() on IServiceCollection / IHostApplicationBuilder that resolves channel connection strings from Aspire's service-discovery mechanism (IConfiguration["ConnectionStrings:..."]) and registers channel statuses with names that match the Aspire dashboard's resource identifiers.
- OpenTelemetry integration: activity spans emitted by the publisher (item 6) are automatically exported to the Aspire dashboard's trace viewer using the Aspire-configured OTLP exporter, with no manual configuration required.
Benefits:
- The Aspire dashboard shows each publish channel as a named resource with real-time health status, eliminating the need to open separate broker management UIs during development.
- Broker containers (RabbitMQ, Kafka, etc.) are provisioned and torn down automatically by Aspire for each developer's local session, removing the static
docker-compose.yml that every team maintains today.
- Trace spans from published events appear in the Aspire dashboard's distributed-trace view alongside HTTP request spans, giving a complete picture of a domain operation in a single tool.
- Follows the standard Aspire component split (
*.Hosting + *.Client) so the integration works correctly with all Aspire deployment targets (local, Azure Container Apps, Kubernetes via Aspire manifest) without any changes to application code.
The problem today: Teams using .NET Aspire as their local orchestration platform must configure Deveel Events channels manually and separately from their Aspire resource graph. There is no Aspire component for the framework, so published events do not appear in the Aspire dashboard, channel health is not surfaced as a resource status, and developers must provision broker containers (RabbitMQ, Azure Service Bus emulator) without the convenience of Aspire's built-in resource integrations.
What we will build: A
Deveel.Events.Publisher.Aspirepackage split into two assemblies following the standard Aspire pattern:Deveel.Events.Publisher.Aspire.Hosting): ProvidesAddEventPublisher()andWithRabbitMqChannel()/WithAzureServiceBusChannel()/ etc. extension methods onIDistributedApplicationBuilderthat wire the framework's channel resources into the Aspire resource graph, configure connection strings, and automatically provision the matching Aspire container resources (e.g.,AddRabbitMQ(),AddAzureServiceBus()) when running locally.Deveel.Events.Publisher.Aspire.Client): ProvidesAddEventPublisherFromAspire()onIServiceCollection/IHostApplicationBuilderthat resolves channel connection strings from Aspire's service-discovery mechanism (IConfiguration["ConnectionStrings:..."]) and registers channel statuses with names that match the Aspire dashboard's resource identifiers.Benefits:
docker-compose.ymlthat every team maintains today.*.Hosting+*.Client) so the integration works correctly with all Aspire deployment targets (local, Azure Container Apps, Kubernetes via Aspire manifest) without any changes to application code.