Support SDK workloads

[timheuer]

Description:
The SDK ships with supporting a set of workloads (Wasm, MAUI, Aspire, and potentially more in the future). The setup-dotnet action should support these as further instructions to actually 'setup' the full dotnet environment as expected, not automatically, but opt-in.

uses: actions/setup-dotnet@v5
with:
  dotnet-version: 8.0.x
  workloads: [maui, aspire]

The expectation is that after SDK would be installed that then command would run dotnet workload update (to ensure manifests are updated) and then dotnet workload install on each item in the array

Justification:
Workloads are a primary way to get additional platform SDK tools and dependencies for key .NET frameworks.

/cc @baronfel

[baronfel]

Love this - one implementation note is that the list of workloads provided can be supplied to dotnet workload install all in one go, because the command takes an array of workloads. This should result in a performance improvement.

One subtlety to the situation is that instead of installing various workloads, we also support dotnet workload restore to acquire the workloads that a given solution or project require - that would be less 'variable' (meaning you wouldn't have to update the list of workloads).

[HarithaVattikuti]

Hello @timheuer
Thank you for creating this feature request. We will investigate it and get back to you as soon as we have some feedback.

[Redth]

There's also now the concept of workload sets.... So, you can install a particular workload set by the version. I would suggest anything done here should (optionally) support specifying a version (pattern)...

uses: actions/setup-dotnet@v5
with:
  dotnet-version: 9.0.x
  workloads:
    version: 9.0.x
    ids: [maui, aspire]

which basically would run dotnet workload install --version 9.0.103 maui aspire

[thomasbach-dk]

There's also now the concept of workload sets.... So, you can install a particular workload set by the version. I would suggest anything done here should (optionally) support specifying a version (pattern)...

uses: actions/setup-dotnet@v5
with:
dotnet-version: 9.0.x
workloads:
version: 9.0.x
ids: [maui, aspire]
which basically would run dotnet workload install --version 9.0.103 maui aspire

I like the idea. But it seems that you cannot be sure that there is a workload version matching the exact SDK version.
For example .NET 9.0.3 (9.0.201) has just been released. But here is no equivalent workload version:

Workload installation failed: Workload version 9.0.201 not found.

I can't figure out if that´s a bug in the 9.0.3 manifest?

[hevilhuy]

There's also now the concept of workload sets.... So, you can install a particular workload set by the version. I would suggest anything done here should (optionally) support specifying a version (pattern)...
uses: actions/setup-dotnet@v5
with:
dotnet-version: 9.0.x
workloads:
version: 9.0.x
ids: [maui, aspire]
which basically would run dotnet workload install --version 9.0.103 maui aspire

I like the idea. But it seems that you cannot be sure that there is a workload version matching the exact SDK version. For example .NET 9.0.3 (9.0.201) has just been released. But here is no equivalent workload version:

Workload installation failed: Workload version 9.0.201 not found.

I can't figure out if that´s a bug in the 9.0.3 manifest?

I am in the same boat

[Redth]

@baronfel @marcpopMSFT perhaps it does make sense to publish the workload set version information in the releases.json index somehow? This would help tie things in for this purpose. Would make it easier to also discern how to find the matching workload set package id for other tooling experiences which I'm finding is a bit of an inexact science right now otherwise.