.NET Aspire for cloud-native orchestration. Covers AppHost configuration, service defaults, resource configuration, service discovery, and the Aspire dashboard. Load this skill when setting up local development orchestration, service discovery, or Aspire-managed infrastructure, or when the user ment

.NET Aspire Core Principles 1. AppHost orchestrates; it is never deployed itself — Aspire's core job is the local development experience: starting services, databases, and message brokers together. Modern Aspire also generates deployment assets ( aspire publish for docker compose/Kubernetes manifests, aspire deploy for Azure Container Apps) — but the AppHost process itself stays a dev/build time tool, not a production runtime. 2. Service defaults are your baseline — The ServiceDefaults project configures OpenTelemetry, health checks, and resilience for all services in one place. 3. Use Aspire integrations — Aspire has built in integrations for PostgreSQL, Redis, RabbitMQ, SQL Server, and more. They handle connection strings, health checks, and tracing automatically. 4. The dashboard is your observability tool — Use the Aspire dashboard for local development tracing, logging, and metrics instead of setting up Seq/Grafana locally. Patterns AppHost Configuration Service Defaults Using Service Defaults in a Project Service to Service Communication Solution Structure with Aspire Anti patterns Don't Deploy the AppHost Process Don't Hardcode Connection Strings with Aspire Don't Skip Service Defaults Decision Guide Scenario Recommendation Local dev with multiple services Aspire AppHost Single project local dev dotnet run is fine, Aspire optional Shared service configuration ServiceDefaults project Database for local dev Aspire AddPostgres() / AddSqlServer() Service discovery Aspire's built in service discovery Production deployment aspire publish (compose/K8s manifests) or aspire deploy (ACA); never the AppHost itself Observability in local dev Aspire dashboard (auto configured)