Discover how .NET Aspire simplifies microservices orchestration, logging, and deployment in .NET 8 and 9. Learn to build and manage cloud-native apps using C#, Blazor, Redis, and Docker with ease.
With the rise of cloud computing, software applications have increasingly become less monolithic.
Even the simplest web application may consist of a Web API backend and a frontend written in MVC, Blazor or some other technology. With microservices and third-party Docker images such as Postgres or Redis, complexity increases.
Developers want to focus on functionality but are increasingly distracted by configuring the interaction of all these component parts, and then configuring them again for deployment.
Introduced as part of .NET 8 and continuing on in .NET 9, Aspire offers an all-in-one solution for these problems, and more besides.
The easiest way to get going with Aspire is to use the .NET Aspire Starter App template, which is available through Visual Studio:
Alternatively, it can be created from the command prompt:
dotnet new aspire-starter --use-redis-cache --output [ProjectName]
The generated solution contains five projects. Three of them are straightforward: a Web API backend, a Blazor frontend and an xUnit test project. Additionally, there are two projects related to Aspire: AppHost and ServiceDefaults.
(Note, if you have an existing project, you can configure it for Aspire via Add ➤ .NET Aspire Orchestrator Support.)
Traditionally, to run a backend and a frontend in Visual Studio, you would need to configure multiple startup projects. Now, you just need to run the AppHost application – which defaults as the startup project. You won’t see your application immediately, instead you’ll get the Aspire dashboard:
Here you can see your two applications, plus a Docker container for a Redis cache. (You will need to have Docker Desktop or an equivalent for this feature to work.)
Click on the frontend endpoint to see the Blazor app and navigate to Weather to verify that data is coming from the backend.
To see the API, click on the apiservice endpoint. (Since .NET 9, Swagger is no longer included automatically in API applications, so you will have to navigate to /weatherforecast to see the data. You can easily add Swagger manually if you want.)
On the Aspire dashboard, you’ll also see links for Console logs, Structured logs, Traces and Metrics. Here you can see in one place logging information from your two applications and from the Redis cache. There’s no longer any need to keep track of multiple consoles with the logs for your separate applications.
.png "Streamline Microservice Development with .NET Aspire in .NET 8")
When developing, your applications are not run as Docker containers, although they can be on deployment. However, there is a wide selection of container images which you can use as part of your application – Redis is just one example included to demonstrate the feature.
Additional containers can be found by right-clicking on the AppHost project and choosing via Add ➤ .NET Aspire Package…
These are simply a subset of NuGet packages, each beginning with ‘Aspire.’ By selecting one you can add it to your application in just the same way that Redis is already included.
Not all published Docker images are available via NuGet, but it’s relatively easy to include a raw image into your application with a bit of additional code.
The main configuration of the application is done in Program.cs in the AppHost project.
Firstly, the Redis cache is added to the application. AddRedis is an extension message that came with the Redis package. The name ‘cache’ is a reference that could be whatever you like.
Next, the API is added to the orchestration. The project name Aspire1.ApiService is converted to the valid C# identifier Aspire1_ApiService by converting the ‘.’ to an ‘_’. Again, the name ‘apiservice’ is free for you to choose.
Finally, the frontend is added, with references to both the cache and the API. These are not dependencies in the C# sense, where one project can access public members of the other. This simply means that Aspire will run up the referenced projects when the application is run.
Before Aspire, a similar result could be achieved using tools such as Docker and Docker Compose. The individual projects could be built as Docker images and then orchestrated into a single application using Docker Compose.
Configuring such a system is done by writing YAML (which may stand for Yet Another Markup Language, or alternatively YAML Ain’t Markup Language). While this is a powerful and flexible way to configure an application, it’s another language to master.
In Aspire, all the configuration is done in C#, as can be seen above. In addition to being a language that developers are familiar with, this also has the benefit of all the IntelliSense and AI support that we get in Visual Studio.
For the frontend to use the API, it must know the correct URL. Without Aspire, the developer must lookup the address of the API from that project’s launchsettings.json and use it in the frontend’s appsettings.json, to be read in Program.cs. Having done this for a development environment, the developer would then have to do the same for the URLs for the deployed application. Once there are several microservices, this can become unmanageable.
Aspire vastly simplifies the entire process. The frontend’s Program.cs configures the address with the following code:
The ‘https+http’ simply says that either protocol can be used, but the ‘apiservice’ is the name that was given to the project in the AppHost’s Program.cs, above. Whatever URL the API is running on, either for development or deployment, will automatically be used by the frontend.
Similarly, in the generated tests in WebTests.cs, the name ‘webfrontend’ is used in place of a specific address for the Blazor app.
Further configuration is done in the ServiceDefaults project. This is where all the telemetry and analytics are configured. For the most part, it can be left as is.
Aspire has much more to offer than there is room to describe here, and at first glance it may seem like a complex solution to a problem you don’t have, which may be so. But if you’re a developer who finds yourself spending more and more time writing YAML, and less doing the programming that you enjoy, then maybe Aspire is for you.
If you found this article interesting you might be interested in our Microsoft.NET Training Courses.
