Aspire

codewithmukesh/dotnet-claude-kit/skills/aspire

by codewithmukesh23300897f4d1No license754 starsListed Oct 8, 2026Updated Oct 8, 2026Repository updated 2 months ago

.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".

Instructions onlyDevOps & Cloud
AI-generated overview

.NET Aspire guidance for local cloud-native orchestration, service defaults, service discovery and the Aspire dashboard.

What it does
This skill provides reference guidance for .NET Aspire, covering AppHost configuration, service defaults, resource configuration, service discovery and the Aspire dashboard. It presents code patterns for wiring infrastructure resources and application projects, plus anti-patterns and a decision guide. It is instruction-only and produces no files or scripts.
When to use it
Use it when setting up local development orchestration, service discovery or Aspire-managed infrastructure in a .NET solution. It also applies when the user mentions Aspire, AppHost, service defaults, service discovery, the Aspire dashboard, AddProject, WithReference or cloud-native .NET.
Requirements
Requires a .NET development context with Aspire tooling; no scripts or credentials are shipped.

.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

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

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)

Source and attribution

Source:codewithmukesh/dotnet-claude-kitinskills/aspireat commit2330089

License: No license

Content belongs to its original authors. SourceWeft indexes it from a public repository.

Report or request removal

More from codewithmukesh/dotnet-claude-kit

Wrap Up

codewithmukesh

Captures end-of-session work, pending tasks and learnings into a handoff file, and reloads it at session start.

Productivity & Workflow754updated 2 months ago

Workflow Mastery

codewithmukesh

Claude Code workflow mastery for .NET developers. Covers parallel execution with git worktrees, plan mode strategy, verification loops, auto-formatting hooks, permission setup for dotnet CLI, prompting techniques, subagent patterns, and context discipline — token budget management, MCP-first navigation, lazy loading, and subagent isolation — all adapted for the .NET ecosystem. Load this skill when setting up Claude Code for a .NET project, optimizing workflows, running parallel sessions, when context is running low or sessions feel sluggish, when exploring a large codebase efficiently, or when the user mentions "productivity", "workflow", "parallel", "worktree", "plan mode", "permissions", "hooks", "10x", "setup Claude Code", "speed up development", "context", "tokens", "budget", "running out of context", "too many files", or "large codebase". Inspired by tips from Boris Cherny (creator of Claude Code) and the Anthropic team.

Awaiting classification754updated 2 months ago

Vertical Slice

codewithmukesh

Guides .NET developers in structuring applications with Vertical Slice Architecture, covering feature folders, endpoint grouping and handler patterns.

Software Development754updated 2 months ago

Testing

codewithmukesh

Testing strategy for .NET 10 applications. Covers xUnit v3, WebApplicationFactory for integration tests, Testcontainers for real database testing, Verify for snapshot testing, and the AAA pattern. Load this skill when writing tests, setting up test infrastructure, reviewing test coverage, or when the user mentions "test", "xUnit", "WebApplicationFactory", "Testcontainers", "integration test", "unit test", "bUnit", "snapshot test", "Verify", "test coverage", "AAA pattern", "WireMock", or "FakeTimeProvider".

Awaiting classification754updated 2 months ago

Tdd

codewithmukesh

Guided test-driven development workflow for .NET 10 using xUnit v3, WebApplicationFactory, Testcontainers, and Verify snapshots. Follows the strict red-green-refactor cycle. Use when: "TDD", "test-driven", "let's TDD this", "red green refactor", "write the test first", or when building a feature with clear acceptance criteria.

Awaiting classification754updated 2 months ago

Spec

codewithmukesh

Turns a vague feature idea into an agreed, persisted specification file through structured questioning rounds.

Productivity & Workflow754updated 2 months ago