Aspire is a code-first way to describe and run a distributed .NET application. Instead of starting each service and infrastructure resource separately, you define them in an AppHost project. Aspire uses that model to start resources together, pass connection information, coordinate dependencies, and show their state and telemetry in a shared dashboard. The services remain independent applications. section 1.0
Start with an online shop: a storefront calls a catalog API. As the system grows, the API needs storage and caching, while checkout hands longer-running work to a background service through a message broker. Each component needs configuration, and a failure may span several processes. Aspire gives those components one place to run and inspect during development. section 1.0 section 1.1
The core pieces have distinct jobs:
- AppHost declares resources and their relationships; registered applications can receive references to one another. section 1.0 section 1.10
- Service defaults provide shared dependencies for hosted applications, while service discovery resolves services by registered name rather than a hardcoded address. section 1.10
- The dashboard brings running-service status together with observability; logs, metrics, and distributed traces help follow failures across service boundaries. section 1.0 section 1.1
Figure 1.1 A shopper’s request crosses the storefront, API, data stores, and background-processing components. Telemetry makes the complete workflow observable.
The workflow diagram shows why a single storefront request can involve an API, data stores, and background processing—and why telemetry must cover the whole path. section 1.1
Version matters when maintaining an existing system. Aspire 9 was released in 2024; Aspire 8 and 9 applications may need modernization to run on Aspire 13. Existing .NET projects and infrastructure components can also be brought into Aspire without replacing their production versions solely to adopt the application model. section 10.0
