Hands on: Microsoft principal product manager Jon Galloway has said that .NET Aspire, a stack for building distributed applications, can in fact be used with any .NET application – and posted a how-to to illustrate this.

According to Galloway, Aspire adds value by improving monitoring and reliability, as well as adding service discovery which might be used in future for adding features such as Redis, an in-memory database often used for caching, or switching to containers for deployment. Aspire became generally available in May, and works with .NET 8.0, the latest LTS (long term support) version.

DevClass tried following Galloway’s instructions with an existing application, using VS Code on a Mac. There is some friction using VS Code, in the Aspire documentation as well as in the new post. This documentation, for example, states that using the Windows-only Visual Studio is optional, but presumes its use further down the page. We had to install the Aspire workload via the command line, using:

sudo dotnet workload install aspire

Next, we quit and restarted VS Code, and then created a new Aspire ServiceDefaults project using the command palette, there being no right-click option for this despite Galloway’s suggestion. We could also have used the .NET CLI (Command Line Interface), which we did for adding a reference to the newly created Aspire project:

dotnet add reference ../ServiceDefaults1/ServiceDefaults1.csproj

Our application was created in .NET 5 and upgraded to .NET 8; but did not yet use the minimal API introduced in .NET 6. The documentation for adding Aspire presumes use of the minimal API so we converted it using the guide here. Next, we edited program.cs with builder.AddServiceDefaults() and app.MapDefaultEndpoints, ran the application, navigated to /health, and were rewarded with the one word “Healthy.” Good to know.

Things became more interesting with the next step. We added a new Aspire AppHost project using the same technique as for ServiceDefaults, then added a reference to our web application to the new AppHost project. A single line of code, following Galloway’s guidance, adds the web application to the ASP.NET builder for the AppHost, which means the AppHost is responsible for launching and monitoring it. Finally, we replaced the VS Code launch.json, which sets the start up project, so that it starts AppHost. 

There was a small glitch in starting the application, because the web browser attempts to connect before it is ready to receive connections and displays an error. This is easy to fix by refreshing the page. What then appears is the Aspire dashboard, with sections for Resources (the projects that are referenced), Console (the standard output from the selected application), Structured logs (with options to filter the log level), Traces where configured, and Metrics for various aspects of performance. The dashboard is documented here.

The AppHost successfully started our web application (though for some reason the dashboard does not show the endpoint, perhaps an error on our part), and as we exercised various features the metrics populated. This is of use when debugging, and would be even more helpful in production, though note that Microsoft warns of security considerations such as display of secrets in environment variables. The dashboard is protected by a browser token and encrypted connections in the debug environment. Deploying it to production though is not so straightforward, though there is a containerized, standalone option that can be configured. Distinguished engineer David Fowler stated in November that the dashboard in the AppHost “won’t just work as its designed to get data locally only.”

Aspire applications are intended to be deployed to Azure Container Apps or to Kubernetes. Deployment is not straightforward, the core reason being, as Fowler notes, that “Aspire provides an orchestrator for development but not for production. If you want to use the aspire model in your deployed application then you need an orchestrator. I’d recommend Kubernetes.”

This being the case, the appeal of adding Aspire to an existing monolithic application is diminished; and there is also the matter of whether it might require some disentangling if developers wish to benefit from Aspire in development but simplify the deployment.

Nevertheless, there is added value here at little cost; and as Aspire matures, various scenarios, such as easy and secure deployment of the dashboard to production, are likely to improve.