aspire-configuration

name	aspire-configuration
description	Configure Aspire AppHost to emit explicit app config via environment variables; keep app code free of Aspire clients and service discovery.
invocable	false

Aspire Configuration

When to Use This Skill

Use this skill when:

• Wiring AppHost resources to application configuration in Aspire-based repos
• Ensuring production configuration is transparent and portable outside of Aspire
• Avoiding Aspire client/service-discovery packages inside application code
• Designing feature toggles for dev/test without changing app code paths

---

Core Principles

1. AppHost owns Aspire infrastructure packages

   • Aspire Hosting packages belong in AppHost only.
   • App projects should not reference Aspire client/service-discovery packages.

2. Explicit configuration only

   • AppHost must translate resource outputs into explicit config keys (env vars).
   • App code binds to IOptions<T> or Configuration only.

3. Production parity and transparency

   • Every value injected by AppHost must be representable in production as env vars or config files without Aspire.
   • Avoid opaque service discovery and implicit configuration.

---

Configuration Flow

AppHost resource -> WithEnvironment(...) -> app config keys -> IOptions<T> in app

The AppHost is responsible for turning Aspire resources into explicit app settings. The application never consumes Aspire clients or service discovery directly.

---

AppHost Patterns (Explicit Mapping)

Example: Database + Blob Storage

// AppHost/Program.cs
var builder = DistributedApplication.CreateBuilder(args);

var postgres = builder.AddPostgres("postgres");
var db = postgres.AddDatabase("appdb");

var minio = builder.AddContainer("minio", "minio/minio")
    .WithArgs("server", "/data")
    .WithHttpEndpoint(targetPort: 9000, name: "http")
    .WithHttpEndpoint(targetPort: 9001, name: "console")
    .WithEnvironment("MINIO_ROOT_USER", "minioadmin")
    .WithEnvironment("MINIO_ROOT_PASSWORD", "minioadmin");

var api = builder.AddProject<Projects.MyApp_Api>("api")
    .WithReference(db, "Postgres")
    .WithEnvironment("BlobStorage__Enabled", "true")
    .WithEnvironment("BlobStorage__ServiceUrl", minio.GetEndpoint("http"))
    .WithEnvironment("BlobStorage__AccessKey", "minioadmin")
    .WithEnvironment("BlobStorage__SecretKey", "minioadmin")
    .WithEnvironment("BlobStorage__Bucket", "attachments")
    .WithEnvironment("BlobStorage__ForcePathStyle", "true");

builder.Build().Run();

Key points

• WithReference(db, "Postgres") sets ConnectionStrings__Postgres explicitly.
• Every external dependency is represented via explicit config keys.
• The API project only reads Configuration values.

---

App Code Pattern (No Aspire Clients)

Application code binds to options and initializes SDKs directly. It never depends on Aspire client packages or service discovery.

// Api/Program.cs
builder.Services
    .AddOptions<BlobStorageOptions>()
    .BindConfiguration("BlobStorage")
    .ValidateDataAnnotations()
    .ValidateOnStart();

builder.Services.AddSingleton<IBlobStorageService>(sp =>
{
    var options = sp.GetRequiredService<IOptions<BlobStorageOptions>>().Value;
    return new S3BlobStorageService(options); // uses explicit options only
});

Do not add Aspire client packages (or AddServiceDiscovery) to the app. Those are orchestration concerns and should stay in AppHost.

---

Feature Toggles and Test Overrides

Keep toggles in config and drive them through AppHost and test fixtures. This maintains parity between dev/test and production configuration.

// AppHost: disable persistence in tests via config overrides
var config = builder.Configuration.GetSection("App")
    .Get<AppHostConfiguration>() ?? new AppHostConfiguration();

if (!config.UseVolumes)
{
    postgres.WithDataVolume(false);
}

api.WithEnvironment("BlobStorage__Enabled", config.EnableBlobStorage.ToString());

See skills/aspire/integration-testing/SKILL.md for patterns on passing configuration overrides into DistributedApplicationTestingBuilder.

---

Do / Don’t Checklist

Do

• Map every Aspire resource output to explicit configuration keys
• Use IOptions<T> with validation for all infrastructure settings
• Keep AppHost as the only place that references Aspire hosting packages
• Ensure any AppHost-injected value can be set in production env vars

Don’t

• Reference Aspire client/service-discovery packages in application projects
• Rely on opaque service discovery that cannot be mirrored in production
• Hide configuration behind Aspire-only abstractions

---

Related Skills

• skills/aspire/service-defaults/SKILL.md
• skills/aspire/integration-testing/SKILL.md
• skills/akka/aspire-configuration/SKILL.md

---

Resources

• Aspire AppHost environment configuration: https://learn.microsoft.com/en-us/dotnet/aspire/fundamentals/app-host
• Configuration in .NET: https://learn.microsoft.com/en-us/dotnet/core/extensions/configuration