Workloads distribution and management is understandable and seamless for developers

[baronfel]

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

• Enable workloads on arm64 #27243
  • We will enable authoring and consumption of workloads that ship arm64 assets and toolchains, to better support those platforms

Workload Usability Enhancements

• Add workload force clean option #19603
• Support workloads installed via Visual Studio from CLI dotnet workload commands #21811
• Improve the first-run experience for workloads - detect common version mismatch scenarios and tell the user the actions to perform to resolve them #31872
• Add design proposal for workload history #30486
  • Workload History (part 4) #42020
• Add design for simplifying workload versioning designs#294
  • Support for SxS workload manifests #32236
  • Support for new Workload Set Versions #35455
• Design for better handling of workload previews for Aspire and Maui
  • This could potentially include preview channels or versions of workloads that customers can flow through.
  • Primary questions are how customers stay on previews and how do they eventually move back to stable
• Provide CLI commands for investigating the contents and available workload set versions #42367
• Improve performance of workload installation #24843
• Improve the workload template experience #42253
  • The currently if workloads get out of sync, the templates vanish. Can we include the templates in the sdk or include a "breadcrumb" template that lets you install the workloads. File new "install maui" would be an improved experience for sure.
• Cannot update workload manifests from authenticated AzDO feeds on macOS #35912

Workload Tooling Enhancements

• We will work with the runtime team to investigate and reduce build-time impact of authoring workloads
• We will make workloads SBOMs (Software Bill of Materials) work with Visual Studio tooling
• We will add metadata to the SDK installation that describes how the SDK was installed (VS, standalone, etc). This will let triage and automated tools detect and perform different actions based on install type.
• Improve error messages reported when a workload is missing #30230
• Automate workload drop creation to streamline insertion process #36442
• Workload messages are busy or unclear #37163
• Investigate telemetry improvements around how users use workloads #42372

This doesn't include any long-tail bug work that the team picks up during the release cycles.