Introduction

.NET Aspire is the latest addition to the .NET ecosystem focused on providing faster cloud-native app development. Rather than dealing with connecting and managing different distributed apps, Aspire provides a set of compatible services and abstractions for a better developer experience with just C# code.

Aspire isn’t a replacement for existing technologies like docker or Kubernetes but rather it provides a set of tools and packages right out of the box to streamline the overall process.

We can either choose to create a new Aspire project from existing templates or add Aspire support to an existing .NET 8 project.

Creating your first Aspire project

Prerequisites

• Aspire SDK either through .NET CLI or Visual Studio installer with the latest Visual Studio version. I will be using Visual Studio for this blog
• Docker or other container runtime (Optional)
• .NET 8+

Once we have the Aspire SDK setup we can get started with building our Aspire project with the .NET Aspire Starter Application template(without the Redis cache option selected)

This template creates 4 different projects for us

• A Blazor server frontend
• A Web API service backend
• An Aspire App host project
• and finally an Aspire Service default project

While the first 2 are your usual .NET projects, let’s focus on Aspire-related projects.

AppHost

The AppHost project is where we orchestrate all our .NET projects, containers, communication services, etc. together.

This project type is just for local development only and isn’t intended for production scenarios. When getting ready for production deployment this project is used as a reference to generate the deployment files for Azure or use external tools like Aspirate for self-hosting.

The Default Apphost project’s Program.cs file contains just a few lines of code.

var builder = DistributedApplication.CreateBuilder(args);

var apiService = builder.AddProject<Projects.Demo_Proj_ApiService>("apiservice");

builder.AddProject<Projects.Demo_Proj_Web>("webfrontend")
 .WithExternalHttpEndpoints()
 .WithReference(apiService);

builder.Build().Run();

This is where we will define our distributed apps and connect them. The main difference for .NET apps when using aspire compared to using something like docker-compose is that we aren’t building and running .NET apps inside containers every time we hit run.

Aspire also provides various components in the form of nuGet packages to connect to popular services like Kafka, Postgres, Qdrant, etc.

Let’s say we want to add a new Qdrant database to our existing solution. We can do it by making the following changes.

First, add the related Qdrant package to our app host project

 <PackageReference Include="Aspire.Hosting.Qdrant" Version="8.0.0" />

Then add the following method in our app host project (Requires docker running)

builder.AddQdrant("qdrantVectorDB")
 .WithExternalHttpEndpoints();

Now when we run the project we have a qdrant db up and running along with our existing apps.

We can also develop our packages for other services or propriety apps using the existing abstractions making it quite flexible.

This isn’t just limited to .NET apps or predefined services, we can add any container apps available on public or private registries through Aspire with a few lines of code. This allows us to quickly spin up distributed applications locally without too much hassle.

ServiceDefaults

The ServiceDefaults Project as the name suggests is just a DLL for extension methods that help add common services like OTLP, and service discovery to our .NET applications. Since this isn’t any different from a regular class library project we can customize it to exactly match our requirements.

If we checked any of our other .NET applications we will see the following lines added by the Aspire support providing a common list of services to all our distributed applications.

----------
builder.AddServiceDefaults();
----------
app.MapDefaultEndpoints();
----------

Aspire Dashboard

There’s one last part of Aspire we haven’t discussed yet and that is the Aspire dashboard. The dashboard is an OTLP server for monitoring our apps. While used in Aspire by default, it isn’t tied to Aspire and can optionally be deployed as a standalone container.

When we run our Apphost project locally we can see all our applications, their console logs, traces, and metrics all in one place through the dashboard.

.NET Aspire enhances cloud-native app development by offering integrated services and abstractions. It simplifies the orchestration of projects and services, and with the Aspire Dashboard, monitoring becomes a breeze. Now that we are familiar with what Aspire is and how it works, in future blogs we will be looking at how to set up a local .NET app with Aspire and Semantic-kernel and connect it with various services.