Should you use .NET Aspire?

.NET Aspire logo

.NET Aspire is a set of NuGet packages, tools, and project templates designed to simplify the creation of distributed applications.

In other words, it introduces a new abstraction layer for cloud-native applications.

Microsoft developed .NET Aspire in response to developers’ requests for a simpler approach the creation of distributed applications. Developers want to focus on business logic, but instead, they often dealing with infrastructure layers.

After some time, Microsoft introduced this new, simple approach to building distributed applications.

.NET Aspire Overview

Before next step, I assume you have already installed .NET Aspire components. If no, go here and install.

After installing it and creating an application, you will see the following solution structure:

.NET Aspire orchestration is a host (.AppHost) where you add and configure services. It serves as the entry point for a .NET Aspire application, an Aspire Orchestrator.

By default, the code creates a local Redis container with a project for an API (apiservice) and a project for a frontend (webfrontend):

var builder = DistributedApplication.CreateBuilder(args);

var cache = builder.AddRedis("cache");

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

builder.AddProject<Projects.Note_Web>("webfrontend")
    .WithExternalHttpEndpoints()
    .WithReference(cache)
    .WaitFor(cache)
    .WithReference(apiService)
    .WaitFor(apiService);

builder.Build().Run();

Also, if you look at the solution, you’ll see a project called .ServiceDefaults. It a shared components for all services.

By default, it includes configurations for OpenTelemetry, HealthChecks, and Service Discovery:

public static TBuilder AddServiceDefaults<TBuilder>(this TBuilder builder) where TBuilder : IHostApplicationBuilder
{
    builder.ConfigureOpenTelemetry();

    builder.AddDefaultHealthChecks();

    builder.Services.AddServiceDiscovery();

    builder.Services.ConfigureHttpClientDefaults(http =>
    {
        // Turn on resilience by default
        http.AddStandardResilienceHandler();

        // Turn on service discovery by default
       http.AddServiceDiscovery();
    });

   // Uncomment the following to restrict the allowed schemes for service discovery.
   // builder.Services.Configure<ServiceDiscoveryOptions>(options =>
   // {
   //     options.AllowedSchemes = ["https"];
   // });

   return builder;
}

The .ApiService and .Web projects are the API and the application itself.

When you start the application, you’ll see the .NET Aspire Dashboard — and I love it! Just take a look.

Resources in .NET Aspire

All the necessary information is in one place, and it’s fantastic!

Metrics in .NET Aspire

My thoughts

To be honest, I have mixed feelings. As I mentioned before, .NET Aspire simplifies cloud-native application development, but at the same time, it also reduces flexibility.

What I mean by it?

First of all, all your projects should be in a single solution. However, in practice, teams often work across multiple repositories, each managed by different teams.

Secondly, I didn’t get a success message when running my application in Docker with Windows containers, it doesn’t start at all.

And since it’s a brand-new technology, it lacks many resources we could use.

When I did research about .NET Aspire I recall another think Micrsoft realeased recently — Dev Home.

Dev Home is a new controle center for Windows providing the ability to monitor projects on you dashboard using widgets.

Microsoft though that it’s very cool to have one thing for monitoring all your projects, pull requests, disk spaces, CPU and RAM in one place.

But now they decided to close it

I see a match between .NET Aspire and Dev Home. To me, it’s a very similar situation, and the type of product feels quite alike.

Have you already started using .NET Aspire? If so, how is it going on?