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).

[v-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.

[v-gowridurgad]

Hi everyone, We have raised PR #693 to address the above requirement by introducing support for a new workloads input. This allows .NET SDK workloads to be installed directly via actions/setup-dotnet. Any feedback or suggestions would be welcome. Thanks in advance!

[v-gowridurgad]

Hi everyone,
We’re excited to share that this feature has been implemented in PR #693. This update introduces support for a new workloads input, allowing .NET SDK workloads to be installed directly via actions/setup-dotnet.


To start using this feature, you can use the actions/setup-dotnet@main branch in your workflows for now, and the changes will be reflected in upcoming releases.


We’ll be closing this issue. Please feel free to reach out if you have any further concerns or need additional assistance.