.NET Aspire 8.2 is shipping today, and you can download or update to today’s release now. While this release doesn’t introduce big new features like in .NET Aspire 8.1, it does improve onboarding, testing, and have other quality of life improvements.
Components have a new name!
One of the major changes you’ll notice in .NET Aspire 8.2 is that .NET Aspire Components are now called “Integrations”! A .NET Aspire Integration is a package that you add to your app that streamlines the process of setting up, starting up, and communicating with prominent cloud services and platforms.
Integrations are used in two ways in project using .NET Aspire:
- As a “Hosting” package added to your AppHost project, letting you easily spin up the resource and connect to it alongside your projects during local development.
- As a package in your app code, for connecting to the resource created in your AppHost, as well as streamlining setup and defaults to lower the burden of adding a new cloud service.
We originally named these “components” because… well… they’re components! But we’ve realized that it’s such an overloaded term in development that we were actually just confusing people (and ourselves). Our documentation has been updated to reflect the change to “Integrations” and we will be using that terminology in our content moving forward.
Testing, testing, and more testing
Another core part of this release has been strengthening our own system to handle how often Integrations are updated. Of course, one of the best ways to do that is… tests! The .NET Aspire team, along with some amazing community contributors, have been bolstering our suite of tests throughout this release so that we can quickly bump a version and make sure it isn’t going to break anything in your apps. A special thank you to our top contributors from the past month – @alirexaa, @davidebbo, and more – for all the great work you brought into 8.2 for us.
Catch up & join .NET Aspire events
Since the launch of .NET Aspire in May, together with the community we have had several event going deeper on development with .NET Aspire.
- Let’s Learn .NET Aspire: A full 2 hour workshop broadcast live in 7 different languages around the world.
- .NET Aspire Developers Day: A full day of .NET Aspire with the product team and community covering all things .NET Aspire with 14 total sessions!
Join us live on September 18th for Azure Developers – .NET Aspire Day where teams across Azure will be highlighting the latest for .NET Aspire developers for cloud development. Register for free today!
Breaking changes
One of the things we are working on for .NET Aspire 9.0 is to allow you to build .NET Aspire 9.0 projects without requiring the .NET Aspire Workload to be installed. We believe this will help in different scenarios, particularly for CI/CD scenarios where you may not want to install the workload on the build machine.
On the 8.2 release we made some progress towards that goal by moving some of the components that used to ship with the workload to separate packages that will get automatically referenced by your project. This change will be mostly transparent to you, but it does mean that in order to use .NET Aspire 8.2, you will need to make sure that you have the latest version of the workload installed as well as make sure that your AppHost project references the latest version of the Aspire.Hosting.AppHost package. Otherwise, you may see a build error similar to this:
xxx.AppHost is a .NET Aspire AppHost project that needs a package reference to Aspire.Hosting.AppHost version 8.2.0 or above to work correctlyTo fix it, as the error message suggests, you can make sure that your AppHost project references the latest version of the Aspire.Hosting.AppHost package. You can do this by making sure your AppHost project file contains the following line:
<PackageReference Include="Aspire.Hosting.AppHost" Version="8.2.0" />
For more information on this change, you can read our pinned GitHub Issue.
Try it out and let us know your feedback 📣
We’re now turning our focus towards .NET Aspire 9.0, which ships at the same time as .NET 9, and would love to hear what YOU want to see in upcoming releases. Feel free to engage on our GitHub, fill out our survey, and visit our What’s New page in our docs to learn more and download today!
Love it. The Aspire slogan should be “Move fast, without breaking things!” 🙂
Just filled out the survey, but I’ll share one of my suggestions here:
Would be nice to have a SignalR integration, that abstracts the hub connection url/port across aspire components. Could be a SignalR server hosted by my app, or a stand-alone process/container. Yesterday, I wanted to share data between my Python ML app and my C#/Blazor front end, and now that I’m spoiled by Aspire, I wanted to ignore urls and ports – I now expect the whole world to be Aspireified! 🙂
Awesome, kudos to the team.
Integrations sound much better than components.
I have big problems updating to version 8.2. When I run the command dotnet workload update the versions listed with dotnet workload list doesn’t change. Visual Studio says that I need to update in order to build regardless of which version of the nuget packages I’m using. Basically I’m stuck and the same goes for our github action where we use dotnet workload restore to make sure everything is up to date. The restore just throws an error and the build can’t proceed.
It might be just me but isn’t the version numbering a bit confusing?
The new version is said to be 8.2. The manifest files seems to be 8.0.100, dotnet workload list reports 8.0.400 and update says that it installs 8.0.401 (even if nothing changes as far as I can see)
Hi there! There are a few workarounds for this issue – you can see them here https://github.com/dotnet/aspire/issues/5501
I had a problem getting workload update to work. I resolved it by removing (unclicking) a reference to a local NuGet repository. I don’t know if it would solve your issue, but it could be worth a try to remove any non “official” NuGet sources.