In less than a year, .NET Aspire has made it from a preview release all the way through to General Availability and its inclusion in Visual Studio. The marketing keeps saying that the important part of .NET Aspire is that it makes apps “cloud-native”, but that is only a fraction of the story – and in my opinion the least important part.

It is my opinion that .NET Aspire is an attempt to bring order to the chaos of the last decade of .NET software development. The most important quote on the documentation is the following:

.NET Aspire is an opinionated stack for building resilient, observable, and configurable cloud-native applications with .NET.

https://devblogs.microsoft.com/dotnet/introducing-dotnet-aspire-simplifying-cloud-native-development-with-dotnet-8/

Note their emphasis on opinionated and not cloud. The last time I’ve seen an effort this concerted to have an opinion on how software should be built was when ASP.NET MVC was released way back in 2009. Let me explain.

.NET Aspire out of the box

When you create a new template with .NET Aspire and launch the “AppHost” project, you get the following:

• A full dashboard listing all services in the project, by default an API and a Blazor (…) UI project
  • It should be noted that these auto-run, no more faffing with launch.json or “Multiple Startup projects” in VS
• Live console output from each running service
• Structured logs and traces powered by OpenTelemetry
• Process metrics (requests per second, CPU usage etc) for each service
• Integration with Docker Desktop or Podman if installed

This is such a massive stake in the ground for what the .NET Development team sees as “best practice” that it puts many open source utilities, projects and cottage industries of internal “frameworks” out of business.

Pre-Aspire times

Released in 2004, Ruby on Rails was taking off as the “cool” web development framework by the late 2000s. All Microsoft had to offer at the time was WebForms on .NET Framework, originally released in 2002.

Ruby on Rails was an MVC based framework promising that every application would be broadly similar, because it favoured “convention over configuration“. This meant that Controllers were in one place, Views were in one place, Models were in one place, and this was common across every project you would encounter.

The .NET team at the time in Microsoft needed to compete with this. WebForms, with its code behind, viewstate and other “hide how HTTP works” horrors was not cutting it. They probably had the internal data that all these cool new startups were all using Rails.

So ASP.NET MVC was born and version 1 was released in 2009, bringing an “opinionated” MVC framework to .NET for the first time. Like Rails, Controllers were where you expected them to be in every project you came across. It was even actually made open source, unlike WebForms.

.NET MVC was wildly popular in the .NET world and continued through to version 5 and then merged with its “Web API” cousin for .NET Core. For a period of time .NET was sane. You could go into a project and – assuming the architects had not gone crazy trying to create job security – find things where they were supposed to be. With .NET Core, the .NET team even finally created a “blessed” dependency injection framework so you didn’t have to argue over NInject, Autofac, Castle Windsor etc.

Where it started going “off the Rails”

The issues with convention over configuration are that

• You have to learn the conventions
• it is hard for an architect to “invent” any new patterns
• There is a bit of boilerplate required to get started

And this is where I believe things started taking a turn for the worse.

The mid 2010s saw the birth of .NET Core, and the original versions looked like we were going to have a clean break from WebForms and other .NET Framework bleakness.

However, for some people following patterns and architectural principles was just too hard – and to placate the WebForms crowd who had been left out of the cold with the release of .NET Core, Razor Pages were born.

Razor Pages promised the same rapid application development experience as WebForms. It even had code-behind like WebForms. At some point during this journey Blazor was invented, putting Razor Pages on steroids and adding even more layers of abstraction and drag’n’drop goodness. Need to know where your business logic goes? Who cares! Just whack it in the file alongside your UI code! Or maybe not! Its your chance to create your own software architecture!

Minimal API project templates also now truly allow your application to be unique, and you can invent any number of ways to get data on the screen. Roll your own fake controller system? Why not! Directly call the database in your GET handler? Cool! Use fastendpoints to er, bring a hybrid Controller/Mediatr CQRS system back? Lets go!

Towards a better future with .NET Aspire (?)

Which is why Aspire excites me.

Who remembers ELMAH? Well, now you don’t need it as its built in to the Aspire UI.

Who remembers MiniProfiler? An amazing add-on that was ported from Ruby to .NET that showed tracing directly in the UI of your app? Well, thats also now built into Aspire via OpenTelemetry.

Previously all of these amazing tools were expected to be developed by the open source community, for free, to make .NET a viable platform. Now Microsoft are building those tools directly into Visual Studio templates, forcing applications to standardise on ways of setting up logging, monitoring and service discovery around best practices decided by the .NET team (with probably a bit of community input). No more Bobs-homemade-logging-framework, no more Garys-custom-OpenTelemetry-sink. If an application is Aspire compatible it will be expected to meet certain standards.

And this means the team have finally brought an opinionated system back to .NET. This is a beautiful thing, but what is next for Aspire?

The menu on the left of the Aspire Dashboard could easily fit in some new tabs. How about:

• Database access, built in CRUD admin panel (maybe I should port CoreAdmin to it…)
• User management
• API browser/test console (like Swagger)
• Visitor analytics

I’m sure a healthy ecosystem of “plugins” will be developed.

Final thoughts

Believe it or not I am actually excited about where Aspire is going. A genuine out of the box value add from the team, finally some standardisation around common components, the dev team having an opinion again, and a return to the days where projects would follow known patterns. Anything that aims to improve the state of .NET apps “in the wild” gets a thumbs up from me.