Choose Aspire Workload Version

[Carlos Harry (LosLobosDev)]

How can I choose a specific version of Aspire? The following command will always picks the latest version, which is not ideal for CI/CD.

dotnet workload install aspire

[Erik O'Leary (onionhammer)]

Maybe you can use dotnet workload restore to get the version that your project wants?

[Jose Perez Rodriguez (joperezr)]

Unfortunately, this will not get you a specific version, it will only look for workloads that you project uses, and then will restore the latest version of those.

[Nathanial P. Howard (OptimusPi)]

https://learn.microsoft.com/en-us/dotnet/core/tools/global-json

Can global.json be used to pin something other than .NET SDK, such as aspire workload?

[Jose Perez Rodriguez (joperezr)]

Not today, but it will be possible really soon. If you want to learn more about this, you can find more info in the following design proposal which is already being implemented: https://github.com/dotnet/designs/blob/16c553b7905e60a83c0c87acaeb3fd192221dca9/accepted/2023/simplify-workload-versioning-implementation.md

[Jose Perez Rodriguez (joperezr)]

This is a great question, @carlosharrycrf. As of today, workloads don't have an easy built-in way to "pin" a specific version, but there has been a lot of thinking in this area so I can share some info that you may find interesting.

• First, I want to start with a way to select a specific workload today. While there is not an easy way to install a specific version of a workload (since by default they will always try to install the latest), there is a built-in way that can act as a "hammer" in order to make sure that you have the version that you want installed, even if it's not the latest. This can be achieved using workload rollback files. The previous link contains more details on the feature, but the TL;DR is that you can create a file, like rollback.txt, with the following contents:

{
 "microsoft.net.sdk.aspire": "8.0.0-preview.3.24105.21/8.0.100"
}

And then just run the regular workload update and install commands with the extra parameter: --from-rollback-file rollback.txt. This means you end up with: dotnet workload update --from-rollback-file rollback.txt and dotnet workload install aspire --from-rollback-file rollback.txt. In this example, it will install aspire version 8.0.0-preview.3.24105.21 as that is the value I passed in the rollback file, but you can change that for whichever aspire version you want, and everything should work. This acts like a hammer, so even if you already have a newer version of aspire, running the above commands will "downgrade" the version of aspire to whichever version you forced it to.

• Second, I also want to mention something that is specific to Aspire. The problem you are hitting is actually something we hit ourselves as well. When we were building the first preview of aspire, we wanted to start consuming it in our dotnet/eshop project, and we also wanted to setup CI/CD there. The problem, was that because we were iterating fast and we couldn't control the version of aspire that got used, CI was frequently broken. For this reason, we wanted to have a way to represent the version of aspire used by a project in source control, and that is what eventually caused us to include a PackageReference to Aspire.Hosting in the AppHost project template. This package reference was mainly added for that reason, as we had ways in the SDK to figure out that a project was an AppHost and could add the PackageReference behind the scenes, but that would mean that you wouldn't have the version being used in source control. For this reason, if you check your AppHost project today, you likely have a PackageReference to Aspire.Hosting which defines which version of Aspire will your project use. This is still not ideal, since it has no effect on the version of the workload that you have installed, but it at least allowed us to have in source control a version to know which workload should be used.

• Finally, we have shared all of this feedback to our good friends at the dotnet/sdk team, which has led them to prioritize a new feature called "Workload sets" which you can find the full design for here if you are interested. The TL;DR, is that they plan to add a feature so that similar to how you can add a global.json to select a specific SDK to be used for your build, you will be able to also add in that global.json a workload set version, which in short will be a way to pin a specific version of each workload used for building your project. This feature is in the works right now, and the current target is for it to land in 3 months or so with 8.0.300. We believe that once that feature is in, it will greatly improve the experience of working in projects that depend on SDK workloads, as you'll be able to have control over the version being used checked-in on source control.

Hope the above makes sense, but if there are any follow up questions, please don't hesitate to ask.

cc: Daniel Plaisted (@dsplaisted), Marc Paine (@marcpopMSFT), Chet Husk (@baronfel)

[Carlos Harry (LosLobosDev)]

Jose Perez Rodriguez (@joperezr) thank for the detailed response. We will try the 'hammer' approach for now and keep an eye out for the "workload sets" feature.

[Erik O'Leary (onionhammer)]

Why does aspire even require a workload?

[Jose Perez Rodriguez (joperezr)]

FYI Eric Erhardt (@eerhardt) David Fowler (@davidfowl) Damian Edwards (@DamianEdwards), Very valid concern, and suggestion.

[Yunus Efendi (yunusefendi52)]

Just wanted to add, working with MAUI which uses workload is really dreaded and annoying. One of the issue I have found about workload is versioning and dotnet/sdk#38953

Also last time I try; workload is not carried over after updating dotnet and I have to update workload all over again

[Jose Perez Rodriguez (joperezr)]

FYI Marc Paine (@marcpopMSFT)

Thanks for the feedback Yunus Efendi (@yunusefendi52), Some of these versioning concerns are being worked on by a new feature called Workload Sets.

[Erik O'Leary (onionhammer)]

Some of these versioning concerns are being worked on by a new feature called Workload Sets.

Any issue I can follow?

[Chet Husk (baronfel)]

Hi Erik O'Leary (@onionhammer) - you can follow the design specs for unified workload versioning and workload sets in dotnet/designs#294. The SDK team's epic for all workload enhancements is dotnet/sdk#30008, with the Workload Set-specific items being tracked in dotnet/sdk#35455.

Hope this helps!