Originales Skill-Dokument
Aus dem Quell-Repository gerendert; Überschriften, Beispiele, Code, Tabellen, Links und Bilder bleiben erhalten.
.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) |
