PluginBench
Skill
Pass
Audit score 90

aspire

codewithmukesh/dotnet-claude-kit

Orchestrate cloud-native .NET services locally with AppHost, service discovery, and integrated observability.

What is aspire?

.NET Aspire provides local development orchestration for multi-service .NET applications, handling service discovery, resource configuration (databases, caches, message brokers), and observability via the Aspire dashboard. Use it when building microservices or multi-project solutions that need coordinated startup, health checks, and tracing.

  • Orchestrate AppHost to start services, databases, and infrastructure together in local development
  • Configure service defaults (OpenTelemetry, health checks, resilience) once and apply across all services
  • Manage service-to-service communication and discovery without hardcoding connection strings
  • Integrate PostgreSQL, Redis, RabbitMQ, SQL Server, and other resources with automatic health checks and tracing
  • Generate deployment assets (docker-compose, Kubernetes manifests) via `aspire publish` or deploy directly to Azure Container Apps
  • Observe local development with the Aspire dashboard for tracing, logging, and metrics

How to install aspire

npx skills add https://github.com/codewithmukesh/dotnet-claude-kit --skill aspire
Claude Code
Cursor
Windsurf
Cline

How to use aspire

  1. 1.Create an AppHost project and define your infrastructure resources (databases, caches, brokers) using `builder.AddPostgres()`, `builder.AddRedis()`, etc.
  2. 2.Create a ServiceDefaults project with shared configuration (OpenTelemetry, health checks, resilience) and call `builder.AddServiceDefaults()` in each service
  3. 3.Add your application projects to the AppHost using `builder.AddProject<>()` and link them with `.WithReference()` to share connection strings and enable service discovery
  4. 4.Configure each service to use Aspire integrations (e.g., `builder.AddNpgsqlDbContext<AppDbContext>()`) instead of hardcoded connection strings
  5. 5.Run the AppHost with `dotnet run` to start all services, databases, and the Aspire dashboard together
  6. 6.For production, use `aspire publish` to generate docker-compose or Kubernetes manifests, or `aspire deploy` for Azure Container Apps

Use cases

Good for
  • Setting up a multi-service microservices architecture with coordinated local development
  • Configuring PostgreSQL, Redis, and RabbitMQ for a .NET application without manual connection strings
  • Implementing service-to-service HTTP communication with automatic service discovery
  • Generating production deployment manifests from your Aspire app model
  • Monitoring local development with OpenTelemetry tracing and metrics in the Aspire dashboard
Who it's for
  • Backend engineers building multi-service .NET applications
  • DevOps engineers setting up local development environments for teams
  • Architects designing cloud-native .NET solutions
  • Teams migrating from manual orchestration to Aspire-managed infrastructure

aspire FAQ

Should I deploy the AppHost process to production?

No. The AppHost is a dev/build-time orchestrator only. Use `aspire publish` to generate deployment manifests (docker-compose, Kubernetes) or `aspire deploy` for Azure Container Apps; deploy those artifacts instead.

How do services discover each other without hardcoding URLs?

Aspire's built-in service discovery allows you to use DNS names like `https+http://service-name` as the base address. The AppHost and ServiceDefaults handle registration and resolution automatically.

What does ServiceDefaults configure?

ServiceDefaults configures OpenTelemetry (logging, metrics, tracing), health checks, service discovery, and HTTP resilience policies. Call `builder.AddServiceDefaults()` in each service to apply these consistently.

Can I use Aspire with a single-project application?

Aspire is optional for single-project apps; `dotnet run` works fine. Aspire shines with multi-service architectures where you need coordinated startup and service discovery.

How do I observe my local development?

The Aspire dashboard is automatically configured and accessible when you run the AppHost. It shows tracing, logging, and metrics for all services without additional setup.

Full instructions (SKILL.md)

Source of truth, from codewithmukesh/dotnet-claude-kit.


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

  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

// 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

// 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

// 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

// 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

// 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

// 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

// BAD — manually configuring each service
builder.Services.AddOpenTelemetry()...
builder.Services.AddHealthChecks()...

// GOOD — use shared service defaults
builder.AddServiceDefaults();

Decision Guide

ScenarioRecommendation
Local dev with multiple servicesAspire AppHost
Single-project local devdotnet run is fine, Aspire optional
Shared service configurationServiceDefaults project
Database for local devAspire AddPostgres() / AddSqlServer()
Service discoveryAspire's built-in service discovery
Production deploymentaspire publish (compose/K8s manifests) or aspire deploy (ACA); never the AppHost itself
Observability in local devAspire dashboard (auto-configured)