<< All versions
Skill v1.0.1
currentAutomated scan100/100codewithmukesh/dotnet-claude-kit/aspire
+3 new
──Details
PublishedAugust 15, 2026 at 05:10 AM
Content Hashsha256:1dc5713bed378a9d...
Git SHA23300897f4d1
Bump Typepatch
──Files
Files (1 file, 5.9 KB)
SKILL.md5.9 KBactive
SKILL.md · 176 lines · 5.9 KB
version: "1.0.1" name: aspire description: > .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 mentions "Aspire", "AppHost", "service defaults", "service discovery", "orchestration", "Aspire dashboard", "AddProject", "WithReference", or "cloud-native .NET".
.NET Aspire
Core Principles
- 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 publishfor docker-compose/Kubernetes manifests,aspire deployfor Azure Container Apps) — but the AppHost process itself stays a dev/build-time tool, not a production runtime. - Service defaults are your baseline — The
ServiceDefaultsproject configures OpenTelemetry, health checks, and resilience for all services in one place. - 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.
- 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
csharp
// AppHost/Program.csvar builder = DistributedApplication.CreateBuilder(args);// Infrastructure resourcesvar postgres = builder.AddPostgres("postgres").WithPgAdmin().AddDatabase("myappdb");var redis = builder.AddRedis("redis").WithRedisInsight();var rabbitmq = builder.AddRabbitMQ("messaging").WithManagementPlugin();// Application projectsvar api = builder.AddProject<Projects.MyApp_Api>("api").WithReference(postgres).WithReference(redis).WithReference(rabbitmq).WithExternalHttpEndpoints();var worker = builder.AddProject<Projects.MyApp_Worker>("worker").WithReference(postgres).WithReference(rabbitmq);builder.Build().Run();
Service Defaults
csharp
// ServiceDefaults/Extensions.cs — Standard Aspire service defaults// Configures OpenTelemetry (metrics + tracing), health checks, service discovery, and resiliencepublic static class Extensions{public static IHostApplicationBuilder AddServiceDefaults(this IHostApplicationBuilder builder){builder.ConfigureOpenTelemetry();builder.AddDefaultHealthChecks();builder.Services.AddServiceDiscovery();builder.Services.ConfigureHttpClientDefaults(http =>{http.AddStandardResilienceHandler();http.AddServiceDiscovery();});return builder;}// ConfigureOpenTelemetry: adds logging, metrics (ASP.NET, HttpClient, Runtime),// tracing (ASP.NET, HttpClient, EF Core), and OTLP exporter if configured// AddDefaultHealthChecks: adds a "self" liveness check tagged ["live"]}
Using Service Defaults in a Project
csharp
// MyApp.Api/Program.csvar builder = WebApplication.CreateBuilder(args);builder.AddServiceDefaults();// Add Aspire integrationsbuilder.AddNpgsqlDbContext<AppDbContext>("myappdb");builder.AddRedisDistributedCache("redis");var app = builder.Build();app.MapDefaultEndpoints(); // health check endpointsapp.Run();
Service-to-Service Communication
csharp
// AppHost — configure service referencesvar orderApi = builder.AddProject<Projects.OrderApi>("order-api");var paymentApi = builder.AddProject<Projects.PaymentApi>("payment-api").WithReference(orderApi); // paymentApi can discover orderApi// In PaymentApi — use service discoverybuilder.Services.AddHttpClient<OrderClient>(client =>{client.BaseAddress = new Uri("https+http://order-api");});
Solution Structure with Aspire
MyApp.slnx├── MyApp.AppHost/ # Aspire orchestrator│ └── Program.cs├── MyApp.ServiceDefaults/ # Shared service configuration│ └── Extensions.cs├── src/│ ├── MyApp.Api/ # Web API project│ └── MyApp.Worker/ # Background worker└── tests/└── MyApp.Api.Tests/
Anti-patterns
Don't Deploy the AppHost Process
csharp
// BAD — running the AppHost executable in production as an orchestrator// The AppHost is a dev/build-time tool, not a production runtime// GOOD — deploy the generated assets, not the AppHost:// aspire publish → docker-compose / Kubernetes manifests from the app model// aspire deploy → direct deployment (e.g., Azure Container Apps)
Don't Hardcode Connection Strings with Aspire
csharp
// BAD — hardcoding connection strings defeats Aspire's purposebuilder.Services.AddDbContext<AppDbContext>(o =>o.UseNpgsql("Host=localhost;Database=myapp;..."));// GOOD — use Aspire integration (connection string injected automatically)builder.AddNpgsqlDbContext<AppDbContext>("myappdb");
Don't Skip Service Defaults
csharp
// BAD — manually configuring each servicebuilder.Services.AddOpenTelemetry()...builder.Services.AddHealthChecks()...// GOOD — use shared service defaultsbuilder.AddServiceDefaults();
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) |