.NET Aspire 8.2 has been officially released, bringing enhancements focused on onboarding, testing, and overall quality-of-life improvements. A significant change in this version is the renaming of Components to Integrations. As explained, the term Integrations now means packages that assist with the setup, initialization, and interaction with major cloud services and platforms.
The .NET Aspire team clarified this change in terminology:
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.
In .NET Aspire 8.2, Integrations are utilized in two main ways. First, as a Hosting package that was added to the AppHost project, which simplifies launching resources and connecting them during local development. Second, as a package within the application code, this makes easier the process of connecting to resources created in the AppHost and simplifies the setup and configuration of new cloud services.
The release also includes improvements in testing procedures. The .NET Aspire team, with contributions from the community, has expanded its suite of tests to ensure that updates to Integrations do not disrupt existing applications. This enhancement aims to facilitate smoother version upgrades and minimize potential issues.
A significant breaking change in .NET Aspire 8.2 involves a known issue with building projects that reference version 8.1.0 when the 8.2.0 workload is installed. Users are advised to ensure their AppHost project references the latest version of the Aspire.Hosting.AppHost package by including the following line in the project file.
<PackageReference Include="Aspire.Hosting.AppHost" Version="8.2.0" />
Looking ahead to .NET Aspire 9.0, the team is working on enabling project builds without requiring the .NET Aspire Workload to be installed. This change is expected to benefit continuous integration and deployment scenarios by reducing the need for workload installation on build machines.
It is also stated that the progress towards this goal has been made in version 8.2 by moving some components to separate packages, which projects will automatically reference. This change is anticipated to be mostly transparent to users but requires updating to the latest version of the workload and package references. An open GitHub issue provides further details on these topics for interested readers.
Community feedback on this release has been generally positive. Users have requested additional features, such as a SignalR Integration to manage hub connection URLs and ports, and improvements in documentation for deployment and issues with Azure App Service. Lastly, the official release notes hold more information about this release for interested readers.
