aspire

Name: aspire
Author: managedcode

461stars35forks

How to install aspire?

managedcode/dotnet-skills/aspire

$npx -y skills add managedcode/dotnet-skills --skill aspire

Installs into the current project.

Summary

Build, upgrade, and operate Aspire 13.4.x C# or TypeScript application hosts with the current CLI, AppHost, ServiceDefaults, integrations, dashboard, testing, MCP, and deployment patterns for distributed apps. USE FOR: Aspire.AppHost.Sdk, Aspire.Hosting.*, DistributedApplication.

Files · 1

View on GitHub

SKILL.md

1	# Aspire
2
3	## Trigger On
4
5	- `Aspire.AppHost.Sdk`, `Aspire.Hosting.*`, `DistributedApplication.CreateBuilder`, `apphost.mts`, `createBuilder`, `WithReference`, `WaitFor`, `AddProject`, `addNodeApp`, `addViteApp`, `AddRedis`, `AddPostgres`, `aspire run`, `aspire init`, `aspire add`, or `aspire update`
6	- `Aspire.Hosting.Testing`, `DistributedApplicationTestingBuilder`, or a test harness that mixes an Aspire AppHost with `WebApplicationFactory`
7	- orchestrating multiple services and resources with an AppHost for local development or cloud deployment
8	- setting up `ServiceDefaults`, service discovery, OpenTelemetry, health checks, or the Aspire Dashboard
9	- choosing between official first-party Aspire integrations and `CommunityToolkit/Aspire`
10	- upgrading older 8.x or 9.x Aspire solutions to the current CLI and AppHost SDK model
11	- wiring polyglot services into an Aspire topology, especially when Go, Bun, Java, Python, or extra dev-time tools enter the picture
12
13	## Workflow
14
15	1. Classify the task first: new AppHost creation, existing-solution enlistment, integration wiring, testing and observability, deployment, or version upgrade.
16	2. Prefer the current Aspire toolchain. Choose a C# AppHost for .NET-first repositories or a TypeScript `apphost.mts` for JavaScript/TypeScript-first repositories; both are first-class in 13.4. Use the Aspire CLI and current SDK-generated app model instead of writing new guidance around the deprecated legacy workload.
17	3. Treat 13.4.x releases as servicing and feature updates for the current CLI-first app model, not a topology rewrite. Keep the Aspire CLI, `Aspire.AppHost.Sdk`, and closely coupled hosting or testing packages on the same line, then rerun the AppHost and deployment checks after `aspire update`.
18	4. Keep the AppHost code-first and topology-focused. Model services, resources, dependencies, endpoints, lifetimes, and parameters there; keep business logic out.
19	5. Keep `ServiceDefaults` narrow. It exists for telemetry, health checks, resilience, and service discovery, not shared domain models or general utility code.
20	6. Prefer official first-party Aspire integrations when they cover the requirement. Use `CommunityToolkit/Aspire` only when the capability gap is real: unsupported language hosts, extra dev infrastructure, or extension packages the official project does not provide.
21	7. Validate the whole distributed system, not one project in isolation. Local success means the AppHost starts cleanly, dependencies resolve through `WithReference`, the dashboard shows the expected resource graph, and end-to-end tests can exercise the topology.
22	8. For integration tests, keep one shared AppHost fixture per test session. Use `Aspire.Hosting.Testing` to boot the distributed app, create `HttpClient` or SignalR clients from the AppHost, and layer `WebApplicationFactory` on top only when tests need direct Host DI, grains, or runtime services.
23	9. When publishing, switch from local containers or emulators to managed resources deliberately and verify which services truly need external endpoints.
24
25	## Architecture
26
27	```mermaid
28	flowchart LR
29	A["Distributed-app task"] --> B{"Need code-first orchestration?"}
30	B -->\|No\| C["Stay in service-level skills such as ASP.NET Core, Worker, or Orleans"]
31	B -->\|Yes\| D["Create or update the AppHost"]
32	D --> E["Model resources and services with `WithReference` and `WaitFor`"]
33	E --> F{"Official Aspire integration exists?"}
34	F -->\|Yes\| G["Use first-party Aspire integration"]
35	F -->\|No or gap remains\| H["Evaluate `CommunityToolkit/Aspire`"]
36	G --> I["Apply `ServiceDefaults`, dashboard, and tests"]
37	H --> I
38	I --> J{"Publishing now?"}
39	J -->\|No\| K["Run locally with `aspire run` or the AppHost project"]
40	J -->\|Yes\| L["Choose `azd`, App Service, or the CLI deploy/publish pipeline"]
41	```
42
43	## Current Guidance
44
45	- AppHost shape: recognize three current first-class forms: an SDK-style C# AppHost project using `Aspire.AppHost.Sdk/<version>`, a file-based C# `apphost.cs`, or a TypeScript `apphost.mts`. For TypeScript, `aspire init --language typescript` writes `aspire.config.json` and the generated `.aspire/modu

People who liked this also viewed

6 picks

Type

aspire

461stars35forks

View on GitHub

How to install aspire?

managedcode/dotnet-skills/aspire

$npx -y skills add managedcode/dotnet-skills --skill aspire

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Aspire
2
3	## Trigger On
4
5	- `Aspire.AppHost.Sdk`, `Aspire.Hosting.*`, `DistributedApplication.CreateBuilder`, `apphost.mts`, `createBuilder`, `WithReference`, `WaitFor`, `AddProject`, `addNodeApp`, `addViteApp`, `AddRedis`, `AddPostgres`, `aspire run`, `aspire init`, `aspire add`, or `aspire update`
6	- `Aspire.Hosting.Testing`, `DistributedApplicationTestingBuilder`, or a test harness that mixes an Aspire AppHost with `WebApplicationFactory`
7	- orchestrating multiple services and resources with an AppHost for local development or cloud deployment
8	- setting up `ServiceDefaults`, service discovery, OpenTelemetry, health checks, or the Aspire Dashboard
9	- choosing between official first-party Aspire integrations and `CommunityToolkit/Aspire`
10	- upgrading older 8.x or 9.x Aspire solutions to the current CLI and AppHost SDK model
11	- wiring polyglot services into an Aspire topology, especially when Go, Bun, Java, Python, or extra dev-time tools enter the picture
12
13	## Workflow
14
15	1. Classify the task first: new AppHost creation, existing-solution enlistment, integration wiring, testing and observability, deployment, or version upgrade.
16	2. Prefer the current Aspire toolchain. Choose a C# AppHost for .NET-first repositories or a TypeScript `apphost.mts` for JavaScript/TypeScript-first repositories; both are first-class in 13.4. Use the Aspire CLI and current SDK-generated app model instead of writing new guidance around the deprecated legacy workload.
17	3. Treat 13.4.x releases as servicing and feature updates for the current CLI-first app model, not a topology rewrite. Keep the Aspire CLI, `Aspire.AppHost.Sdk`, and closely coupled hosting or testing packages on the same line, then rerun the AppHost and deployment checks after `aspire update`.
18	4. Keep the AppHost code-first and topology-focused. Model services, resources, dependencies, endpoints, lifetimes, and parameters there; keep business logic out.
19	5. Keep `ServiceDefaults` narrow. It exists for telemetry, health checks, resilience, and service discovery, not shared domain models or general utility code.
20	6. Prefer official first-party Aspire integrations when they cover the requirement. Use `CommunityToolkit/Aspire` only when the capability gap is real: unsupported language hosts, extra dev infrastructure, or extension packages the official project does not provide.
21	7. Validate the whole distributed system, not one project in isolation. Local success means the AppHost starts cleanly, dependencies resolve through `WithReference`, the dashboard shows the expected resource graph, and end-to-end tests can exercise the topology.
22	8. For integration tests, keep one shared AppHost fixture per test session. Use `Aspire.Hosting.Testing` to boot the distributed app, create `HttpClient` or SignalR clients from the AppHost, and layer `WebApplicationFactory` on top only when tests need direct Host DI, grains, or runtime services.
23	9. When publishing, switch from local containers or emulators to managed resources deliberately and verify which services truly need external endpoints.
24
25	## Architecture
26
27	```mermaid
28	flowchart LR
29	A["Distributed-app task"] --> B{"Need code-first orchestration?"}
30	B -->\|No\| C["Stay in service-level skills such as ASP.NET Core, Worker, or Orleans"]
31	B -->\|Yes\| D["Create or update the AppHost"]
32	D --> E["Model resources and services with `WithReference` and `WaitFor`"]
33	E --> F{"Official Aspire integration exists?"}
34	F -->\|Yes\| G["Use first-party Aspire integration"]
35	F -->\|No or gap remains\| H["Evaluate `CommunityToolkit/Aspire`"]
36	G --> I["Apply `ServiceDefaults`, dashboard, and tests"]
37	H --> I
38	I --> J{"Publishing now?"}
39	J -->\|No\| K["Run locally with `aspire run` or the AppHost project"]
40	J -->\|Yes\| L["Choose `azd`, App Service, or the CLI deploy/publish pipeline"]
41	```
42
43	## Current Guidance
44
45	- AppHost shape: recognize three current first-class forms: an SDK-style C# AppHost project using `Aspire.AppHost.Sdk/<version>`, a file-based C# `apphost.cs`, or a TypeScript `apphost.mts`. For TypeScript, `aspire init --language typescript` writes `aspire.config.json` and the generated `.aspire/modu

People who liked this also viewed

6 picks

Type