How to use
- Copy the installation command and review the source package before installing it in your own agent environment.
- Check the source document for required tools, credentials and supported hosts.
- Describe your input and desired deliverable; review the output against the source material.
npx skills add https://github.com/codewithmukesh/dotnet-claude-kit --skill aspireBefore you start
- Installation does not include a model subscription, API allowance or permission to access your files.
- Repository stars and installation counts describe activity, not an independent quality or security test.
Original skill document
Rendered from the source repository. Headings, examples, code, tables, links, and referenced images are preserved.
.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.cs
var builder = DistributedApplication.CreateBuilder(args);
// Infrastructure resources
var postgres = builder.AddPostgres("postgres")
.WithPgAdmin()
.AddDatabase("myappdb");
var redis = builder.AddRedis("redis")
.WithRedisInsight();
var rabbitmq = builder.AddRabbitMQ("messaging")
.WithManagementPlugin();
// Application projects
var 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 resilience
public 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.cs
var builder = WebApplication.CreateBuilder(args);
builder.AddServiceDefaults();
// Add Aspire integrations
builder.AddNpgsqlDbContext<AppDbContext>("myappdb");
builder.AddRedisDistributedCache("redis");
var app = builder.Build();
app.MapDefaultEndpoints(); // health check endpoints
app.Run();Service-to-Service Communication
csharp
// AppHost — configure service references
var 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 discovery
builder.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 purpose
builder.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 service
builder.Services.AddOpenTelemetry()...
builder.Services.AddHealthChecks()...
// GOOD — use shared service defaults
builder.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) |
