At its Build event under way in Seattle, Microsoft has released the first production build of .NET Aspire, described as an “opinionated, cloud ready stack” for distributed applications.

According to .NET principal architect Damian Edwards, “developers are increasingly pulled away from their business logic and what matters most to deal with the complexity of the cloud.” The idea of Aspire is to improve the local development experience for distributed .NET applications, as well as providing “new deployment experiences when using deployment toolchains that have been updated to utilize it.” 

Edwards emphasized though that Aspire-developed applications can still be deployed using existing methods since the component projects are “regular ASP.NET Core.”

.NET Aspire is a big project, including messaging, service discovery, caching and monitoring. A dashboard application is part of Aspire, and lists all the containers and executables included in a project with their state, error counts, up time, and logs. 

An Aspire application begins with an app host project which orchestrates all the projects that are part of the full application – though this is not intended to replace production orchestration when deployed to Kubernetes, for example. This app host project simplifies development, making it easy to add common resources such as RabbitMQ for messaging, Redis for caching, Kafka for event streaming, and databases including MongoDB, MySQL, Oracle, and Microsoft’s SQL Server. 

Aspire works with Nuget packages and container runtimes Docker or Podman in order to create a working local development environment for testing and debugging. There is also a testing project template for functional, integration and unit tests.

Regarding deployment, currently Aspire supports deployment to Azure Container Apps, using the bicep domain-specific language or the Azure Developer CLI (command-line interface). 

Another option is to deploy to Kubernetes, either by creating manifests manually or by using a separate project called Aspir8 which will generate deployment YAML automatically, based on the app host project.

The documentation promises that “the number of environments .NET Aspire can deploy to will grow over time,” but as one might expect, the project is currently Azure-centric. We did spot Aspire.Hosting.AWS and Aspire.Hosting.AWS.CloudFormation namespaces in the Aspire API.

Development does not require Visual Studio or Windows, but can be done with Visual Studio Code or even with the .NET command line and an editor of choice. From the command line, <code>dotnet workload install aspire</code> will pull down the necessary components to get started.

The Aspire FAQ tackles some obvious questions. Why not use Docker Compose? Aspire is less complex, does not always require containers, and “produces a better experience,” claims Microsoft. Compose can be used with many different development stacks, whereas Aspire is for .NET 8.0. 

There is also a “big bet on .NET’s integration with OpenTelemetry,” the FAQ states, and indeed the inclusion of the monitoring dashboard is a considerable attraction for potential Aspire developers.

Aspire also integrates with the Orleans distributed actor-based framework, and the Dapr side-car project.