1 Getting Started with .NET Aspire
This chapter introduces .NET Aspire, unveiled alongside .NET 8 and C# 12, as a cloud-native application stack that quickly gained traction by making local development and debugging of distributed applications simple and production-like. It outlines the book’s goal: to teach the core principles behind Aspire so developers can confidently build, run, observe, and deploy multi-service .NET solutions. The chapter begins with a high-level orientation to distributed applications and orchestration, then shows how Aspire streamlines the entire experience.
It explains distributed systems in contrast to modular monoliths, highlighting why teams adopt them—independent deployment and scaling, technology diversity, resilience, and faster delivery—while acknowledging their costs, such as operational complexity, testing challenges, network issues, security surface area, and potential performance overhead. Orchestration is presented as the antidote to this complexity, encompassing deployment, scaling, load balancing, health monitoring and self-healing, configuration and secrets management, and resource allocation across services.
The practical walkthrough uses the Aspire Starter Project to show the AppHost orchestrator launching a Blazor UI and an API, with their state, endpoints, and logs visible in the Aspire dashboard. It covers registering projects with the distributed application builder, declaring dependencies and startup order, controlling external exposure, and enabling service discovery so services communicate via logical names resolved at runtime. The Service Defaults library supplies reusable extensions for health checks, resilient HTTP, service discovery, and OpenTelemetry-based logging, tracing, and metrics. Altogether, Aspire removes boilerplate, unifies local and production-like execution, and boosts developer productivity while remaining cloud-ready for deployment to any host.
Example of a distributed application
Modular monolith structure
Orchestrated system
Hosting code and infrastructure components in the same Aspire process
The structure of the Aspire solution
Aspire dashboard
Aspire console log
Aspire Resources webfrontend link
Blazor app hosted in Aspire
Summary
- .NET Aspire was created by Microsoft to make the process of developing distributed applications easy.
- Distributed applications are systems that consist of multiple independent services that interact with each other.
- Orchestration is the process of coordinating services inside a distributed system
- The main benefit of using .NET Aspire is that it allows running and debugging a distributed application in a single process on a development machine, which substantially simplifies the development process
- .NET Aspire consists of the Aspire Host project that all other projects can connect to
- Different applications hosted by .NET Aspire can pass each other’s references to each other when they are registered by the orchestrator
- The Service Defaults project is used for shared dependencies that any Aspire-hosted apps can use
- Service discovery allows to resolve addresses of Aspire-hosted apps via the names the apps were registered under in the orchestrator
- Aspire orchestrator displays a dashboard, which shows the status of all running services
FAQ
What is .NET Aspire and why did it gain attention?
.NET Aspire is a cloud-native application stack and orchestrator that simplifies building, running, and monitoring distributed applications with .NET. Released alongside .NET 8 and C# 12, it stood out by enabling developers to run and debug entire multi-service systems locally in one orchestrated experience, integrate infrastructure components easily, and get built-in observability—leading to rapid community adoption.How do distributed applications differ from monolithic applications?
A distributed application is a set of autonomous services, each running in its own process and communicating via lightweight mechanisms (often HTTP). Services are built around business capabilities and can be developed, deployed, and scaled independently. A monolith, even a modular one, packages all business logic into a single executable.What are the main benefits of distributed systems?
- Scalability: Scale services independently.
- Flexibility and agility: Teams ship changes without affecting the whole system.
- Technology diversity: Use the best tool per service via tech-agnostic interfaces.
- Resilience and fault isolation: Failures are contained to a service.
- Easier maintenance: Smaller, focused services are simpler to understand and debug.
- Scalable development: Multiple teams can work in parallel.
- Improved deployment/continuous delivery: Ship updates per service.
What are the key challenges of distributed systems?
- Complexity: Inter-service communication, consistency, and orchestration.
- Operational overhead: Deploying, monitoring, and scaling many services.
- Network-related issues: Latency, failures, and data consistency.
- Testing complexity: Coordinated end-to-end testing across services.
- Potential performance overhead: Network calls between services.
- Security: More networked surfaces to protect.
- Initial effort: Careful service boundaries and infrastructure setup.
What is orchestration in the context of distributed systems?
Orchestration manages and coordinates services so they work together reliably. Core aspects include deployment, scaling, load balancing, health monitoring and self-healing, configuration management (including secrets), and resource allocation across CPU, memory, and storage.How does .NET Aspire simplify building and running distributed apps?
It provides a streamlined, declarative model to define services and dependencies, runs code and infrastructure components together in the same orchestrated process for local development, integrates observability (e.g., OpenTelemetry) out of the box, and is cloud-ready for smooth transition from local to production.What is included in the Aspire Starter Project?
The template typically includes:- AspireApp.Web: A Blazor UI that calls a REST API.
- AspireApp.ApiService: The REST API.
- AspireApp.AppHost: The orchestrator that runs and coordinates services.
- AspireApp.ServiceDefaults: A class library of extension methods (telemetry, health checks, service discovery, HTTP client defaults) shared by orchestrated apps.
How do I run an Aspire solution and what does the dashboard show?
Start the host application (e.g.,AspireApp.AppHost). The Aspire dashboard lists each service’s type, unique name, state, source project, endpoints, logs, and details. You can click endpoints to navigate to running services. Under an HTTP profile, each service exposes a single HTTP endpoint; HTTPS profiles show HTTP and HTTPS.How are services registered and wired in the AppHost?
UseDistributedApplication.CreateBuilder(args) to create the builder, then register projects with AddProject<Projects.ProjectName>("servicename"). The Projects.* generic types are auto-generated from project names. For dependencies and startup order, use:.WithReference(otherService)to enable service discovery references..WaitFor(otherService)to ensure startup after a dependency is ready..WithExternalHttpEndpoints()to expose endpoints outside Aspire’s internal network.
What are Service Defaults and how are they used?
Service Defaults is a customizable library of extension methods applied in app startup to standardize cross-cutting concerns. Key methods include:AddServiceDefaults(): Registers service discovery, HTTP client defaults with resilience, telemetry, and health checks.ConfigureOpenTelemetry()andAddOpenTelemetryExporters(): Configure logging, metrics, tracing, and exporters (e.g., OTLP viaOTEL_EXPORTER_OTLP_ENDPOINT).AddDefaultHealthChecks()andMapDefaultEndpoints(): Provide health endpoints like/healthand/alivein development.
builder.AddServiceDefaults() and app.MapDefaultEndpoints() in Program.cs.How does service discovery work in .NET Aspire and how do I call another service?
Install and registerMicrosoft.Extensions.ServiceDiscovery (often via AddServiceDefaults()). Reference dependencies in AppHost with .WithReference(). In the calling app, set HTTP client base addresses using service names, for example: new("https+http://apiservice"). Aspire resolves the actual address at runtime; the https+http scheme prefers HTTPS and falls back to HTTP if needed.
.NET Aspire Made Easy ebook for free
