{"id":53077,"date":"2024-08-07T10:05:00","date_gmt":"2024-08-07T17:05:00","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/dotnet\/?p=53077"},"modified":"2025-11-12T12:02:08","modified_gmt":"2025-11-12T20:02:08","slug":"adding-dotnet-aspire-to-your-existing-dotnet-apps","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/dotnet\/adding-dotnet-aspire-to-your-existing-dotnet-apps\/","title":{"rendered":"Adding Aspire to your existing .NET apps"},"content":{"rendered":"

Aspire<\/a> is a new cloud-ready stack tailored for .NET, enabling developers to quickly and easily develop distributed applications. You’ve probably seen demos showing large .NET solutions with lots of fancy cloud dependencies and thought, well, maybe I’d use that someday if I’m starting on a giant enterprise Redis Kafka Postgres cloud-a-ganza, but it’s not really something I can use today.<\/p>\n

But Aspire is not just about cutting-edge technology and green-field apps; it’s also about making your current applications more straightforward. With Aspire, you can streamline the startup process, improve monitoring, and increase the reliability of your applications. Plus, you can use service discovery to enhance your apps, even if you’re not ready to use more complex features or services like Redis or containerized deployment.<\/p>\n

In this post, we’ll look at how easy it is to make your existing solutions better<\/strong> \u2013 just easier to maintain and add the kind of features you’re already working on. And, sure, it’s nice that you can more easily integrate more sophisticated cloud dependencies and features\u2026 but even if you never do it’s still a win.<\/p>\n

TLDR<\/strong>: In under 5 minutes you can add Aspire to your existing apps and get a dashboard, health checks, and more… all without changing how your apps work, your CI\/CD pipeline, or deployment process.<\/p>\n

What even is Aspire?<\/h2>\n

If you ask five people, you will most likely get five different answers. Honestly, it’s a little hard to describe, and attempts to do it briefly can turn into a bit of buzzword bingo. Really, it’s just a way to solve a problem: building distributed applications is hard<\/strong>. Even just running your app requires starting up one or more services and a front-end and making sure they can talk to each other can be frustrating. Wouldn’t it be nice if that was easier? That is what Aspire aims to do, be your building blocks for your distributed applications making them more observable, resilient, scalable, and manageable.<\/p>\n

Let’s take a look at how a lot of applications evolve over time. A lot start as a single monolithic proof of concept. You’ve got an app with a database.<\/p>\n

\"Diagram<\/p>\n

Assuming your proof of concept is successful, just about every modern app evolves to include at least a front and back-end, in addition to the database.<\/p>\n

\"Diagram<\/p>\n

And then, maybe, if our app’s usage and functionality keeps growing over time, the app will become really distributed, relying on a large set of distributed dependencies.<\/p>\n

\"Diagram<\/p>\n

But here’s the important thing! Even in the really simple Proof Of Concept phase, and definitely in the Frontend-Backend-Database phase, we can benefit from Aspire! With just a few lines of code, and without messing with our CI or deployment, we can really simplify our day-to-day developer experience.<\/p>\n

Step 1: Turn on .NET features we’ve been too busy to turn on with ServiceDefaults<\/h2>\n

The ASP.NET Core team has been lighting up features for cool features for things like tracing, health checks, and resiliency for years. I’ve done half a dozen conference talks on “The One Hour ASP.NET Makeover” where we just turn on and configure all these cool features that have been in the box for years. But here’s the thing… it takes an hour to do that talk, after reading the docs and practicing! What if I could just flip an “Enable Pro Mode” switch instead?<\/p>\n

That’s what Service Defaults does for you. You can just turn on Service Defaults and you’ve got smart logging, health checks, resiliency, etc. based on what the .NET team recommends for ASP.NET Core apps and services. If you want, you can easily edit the Program.cs<\/code> file in the ServiceDefaults<\/em> project, but you don’t have to. Just turn it on.<\/p>\n

Adding a ServiceDefaults project<\/h3>\n

Let’s look at an example with a simple Frontend \u2013 Backend app. I’ll use Jeff Fritz’s new MyWeatherHub<\/em> sample from the Let’s Learn Aspire<\/a> event series, starting with the start-with-api<\/a> code.<\/p>\n

Opening the solution, we’ll see that we’ve got two projects:<\/p>\n