As part of .NET 8, the SDK will continue to invest in the workloads distribution mechanism. We will iterate to make it
able to work for more scenarios, make management and authoring of workloads easier for users and partner teams, and also expand
the use of workloads to include the SDK itself.
Jobs to be done
- Developers can manage different workload versions for different projects on the same machine
- Developers can quickly switch versions of workloads (and even use older/lower versions) without impacting other projects on the machine
- Developers can use the same workloads from VS and the CLI - the two are always in agreement
The first two we aim to solve with the introduction of side by side workloads and workload sets/SDK-level workload versions. These would allow easily 'pinning' specific workloads versions once a new, named manifest is created as part of our release/publishing process. This is sort-of equivalent to a named rollback file in nature. The resolver would learn to use this new system, and since VS and the CLI both use the resolver, both systems would adhere to any pinning behaviors the user has specified.
The latter we aim to solve by introducing a first-run experience for the CLI to keep workloads up to date - since VS updates can impact workload manifests, this first-run mechanism would inspect the state of the system when the SDK was run, and perform any workload restore/install commands required to ensure that the same workloads and versions installed by VS are recognized by the CLI.
Expected work streams
The below list is our anticipated work items for .NET 8. We will continue to update this list as we get more clarity on the
work items and their priority. This is a best-effort list - circumstances may dictate that we put certain items on hold, or
change the order of the items. This list in not in any particular priority order.
Workload capabilities
Workload Usability Enhancements
Workload Tooling Enhancements
This doesn't include any long-tail bug work that the team picks up during the release cycles.
As part of .NET 8, the SDK will continue to invest in the workloads distribution mechanism. We will iterate to make it
able to work for more scenarios, make management and authoring of workloads easier for users and partner teams, and also expand
the use of workloads to include the SDK itself.
Jobs to be done
The first two we aim to solve with the introduction of side by side workloads and workload sets/SDK-level workload versions. These would allow easily 'pinning' specific workloads versions once a new, named manifest is created as part of our release/publishing process. This is sort-of equivalent to a named rollback file in nature. The resolver would learn to use this new system, and since VS and the CLI both use the resolver, both systems would adhere to any pinning behaviors the user has specified.
The latter we aim to solve by introducing a first-run experience for the CLI to keep workloads up to date - since VS updates can impact workload manifests, this first-run mechanism would inspect the state of the system when the SDK was run, and perform any workload restore/install commands required to ensure that the same workloads and versions installed by VS are recognized by the CLI.
Expected work streams
The below list is our anticipated work items for .NET 8. We will continue to update this list as we get more clarity on the
work items and their priority. This is a best-effort list - circumstances may dictate that we put certain items on hold, or
change the order of the items. This list in not in any particular priority order.
Workload capabilities
Workload Usability Enhancements
dotnet workloadcommands #21811Workload Tooling Enhancements
This doesn't include any long-tail bug work that the team picks up during the release cycles.