.NET SDK workloads overview spec

[richlander]

This document is an overview spec for a new concept -- workloads -- that remove the need to add new scenarios to the SDK (like Xamarin) in order to support them with .NET 5+. It will also enable us to remove workloads, like ASP.NET Core, and Windows Forms, from the SDK over time. The goal is to make the SDK super small and focused.

We will add more detailed specs on this topic in other PRs. See:

• Add spec for MinimumOSVersion. #97
• Add spec for workload resolution in MSBuild #104

[KathleenDollard]

Great!

I am concerned that it is only at the end we talk about timing. Other comments in line.

[stevenbrix]

We expect that workload manifests will need to be re-published for each SDK version train. That's an unfortunate requirement, however, the SDK version trains are a compatibility boundary that we would like to maintain.

I'm not entirely sure what this means, are you referring to the Nuget package that defines the component workload?

[richlander]

Yes.

[Nirmal4G]

What happened to the Sdks concept?. Instead of introducing a new one, we should expand the capabilities of the Sdk concept.

There are already Framework packs (older MetaPackages and TargetingPacks). We should use those to provide a modular SDK.

For E.g.:

<Vendor>.<Platform>.Sdk -> meta SDK for a platform provides a composite set of SDKs that provide various technology targets to build on.

Let's take an example of Windows platform. It has WPF, WinForms, UAP, WinNT APIs
you can essentially have...

Microsoft.Windows.Sdk, Microsoft.Windows.Universal.Sdk (UAP) and Microsoft.Windows.Desktop.Sdk (WindowsForms + WPF)

similarly for other platforms, you can have Xamarin.Apple.Sdk, Xamarin.Android.Sdk.

Common cross IDE support tools can also be provided via these packages as well in the form of a format <Vendor>.<Platform/Tech>.Tools.Sdk or ProjectSystem.Sdk or something similar.

You can also generate the AutoImport.<props/targets> in MSBuildProjectExtensionsPath based on the target in the project file if the user doesn't have the required Sdks/Frameworks installed so that It can be resolved from NuGet and placed under ~\.dotnet\sdks\, ~\.dotnet\packs or ~\.dotnet\frameworks, ~\.dotnet\libraries and ~\.dotnet\tools.

[richlander]

What happened to the Sdks concept?. Instead of introducing a new one, we should expand the capabilities of the Sdk concept.

This is a great question. We are continued to support and improve msbuild SDKs for third party scenarios. #104 deals with this topic.

We are now using that mechanism for this feature because we want to avoid using NuGet for any aspect of the platform for reasons that are described in the doc.

Make sense?

[richlander]

Thanks for the feedback so far! I will merge this document in a few days if I don't hear any more feedback. We are still early in the release, so I am sure that there will be more changes and feedback after that.

[Nirmal4G]

we want to avoid using NuGet

You can avoid NuGet since Sdk design is not limited to just NuGet Packages, they can be applied outside of it.

[stephentoub]

Suggested change

In .NET 5, we will add support for iOS, Android, and Web assembly projects. Up until .NET 5.0, we’ve delivered all supported workloads via a monolithic SDK. As the supported workloads of the .NET SDK grow (and we want them to), it is no longer tenable to deliver an "all-in-one / one-size-fits-all" SDK distribution. There are many challenges to a large monolithic SDK, with product build time and distribution size being the most significant. Instead, all new workloads will be built and delivered separately from the SDK, and will be acquirable via your favorite installation tool (like the Visual Studio Installer, a Linux package manager, or the .NET CLI). In the fullness of time, we intend for all .NET workloads to follow this pattern, resulting in a very small and focused SDK.

In .NET 5, we will add support for iOS, Android, and Web assembly projects. Up until .NET 5, we’ve delivered all supported workloads via a monolithic SDK. As the supported workloads of the .NET SDK grow (and we want them to), it will no longer be tenable to deliver an "all-in-one / one-size-fits-all" SDK distribution. There are many challenges to a large monolithic SDK, with product build time and distribution size being the most significant. Instead, all new workloads will be built and delivered separately from the SDK, and will be acquirable via your favorite installation tool (like the Visual Studio Installer, a Linux package manager, or the .NET CLI). In the fullness of time, we intend for all .NET workloads to follow this pattern, resulting in a very small and focused SDK.

[stephentoub]

If they are "out of alignment in some way", what will tools do instead of error'ing? Is this comment saying that this is a valid situation that tools need to handle, and if so, what is the intended outcome?

[richlander]

I took another run at that text.