.NET SDK workloads overview spec #100

richlander · 2020-03-24T20:07:37Z

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:

KathleenDollard

Great!

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

accepted/2020/workloads/workloads.md

stevenbrix · 2020-03-26T15:41:01Z

accepted/2020/workloads/workloads.md

+
+### SDK and workload versioning
+
+Another benefit of the existing monolithic SDK is that the workloads it includes are known to be compatible with core SDK components, like the C# compiler, NuGet, MSBuild, and the SDK targets. Over time, we have developed the concept of an SDK version train. These are represented by SDK version hundreds bands like `3.1.100` and `3.1.200`. These version trains were created to align with Visual Studio versions, like `16.4` and `16.5`. We do this because those same core SDK components are shared between Visual Studio and the .NET SDK, and need to stay in alignment. In addition, new major versions of those components, possibly containing a new language version, can be delivered in these updates. 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.


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?

accepted/2020/workloads/workloads.md

Nirmal4G · 2020-04-06T17:42:00Z

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.

Co-Authored-By: Kathleen Dollard <[email protected]> Co-Authored-By: Steve Kirbach <[email protected]>

richlander · 2020-04-08T04:45:45Z

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 · 2020-04-08T04:47:50Z

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 · 2020-04-08T11:02:05Z

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.

accepted/2020/workloads/workloads.md

stephentoub · 2020-04-08T12:59:08Z

accepted/2020/workloads/workloads.md

@@ -0,0 +1,97 @@
+# .NET Optional SDK Workloads
+
+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.


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 · 2020-04-08T13:02:52Z

accepted/2020/workloads/workloads.md

+* The workload manifest is included as a required dependency for all variants of the workload (some packs might be optional).
+* All referenced packs are included, matching the version specified in the workload manifest.
+
+It should never be obvious to users that there is a compositional model at play. In particular, .NET tools should not produce errors because the workload manifest and required files are out of alignment in some way.


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?

I took another run at that text.

accepted/2020/workloads/workloads.md

Co-Authored-By: Stephen Toub <[email protected]>

Add workloads overview spec

b1ef093

richlander changed the title ~~Add workloads overview spec~~ .NET SDK workloads overview spec Mar 24, 2020

KathleenDollard reviewed Mar 25, 2020

View reviewed changes

rolfbjarne reviewed Mar 26, 2020

View reviewed changes

accepted/2020/workloads/workloads.md Outdated Show resolved Hide resolved

stevenbrix reviewed Mar 26, 2020

View reviewed changes

dsplaisted mentioned this pull request Mar 27, 2020

Add spec for workload resolution in MSBuild #104

Merged

akoeplinger reviewed Mar 27, 2020

View reviewed changes

accepted/2020/workloads/workloads.md Show resolved Hide resolved

richlander and others added 2 commits April 7, 2020 20:29

Apply suggestions from code review

87c0333

Co-Authored-By: Kathleen Dollard <[email protected]> Co-Authored-By: Steve Kirbach <[email protected]>

Update per feedback

192a0c7

Update per feedback

6554b08

stephentoub reviewed Apr 8, 2020

View reviewed changes

accepted/2020/workloads/workloads.md Outdated Show resolved Hide resolved

stephentoub reviewed Apr 8, 2020

View reviewed changes

accepted/2020/workloads/workloads.md Outdated Show resolved Hide resolved

stephentoub reviewed Apr 8, 2020

View reviewed changes

accepted/2020/workloads/workloads.md Outdated Show resolved Hide resolved

richlander commented Apr 8, 2020

View reviewed changes

accepted/2020/workloads/workloads.md Outdated Show resolved Hide resolved

richlander and others added 3 commits April 8, 2020 07:44

Apply suggestions from code review

53da1aa

Co-Authored-By: Stephen Toub <[email protected]>

Remove awkward wording

2ca86cf

Update per feedback

4e5145b

richlander merged commit d4018c9 into master Apr 10, 2020

jkotas deleted the workloads branch April 29, 2020 15:56

genalt mentioned this pull request Jul 30, 2020

Epic: Support optional SDK workload templates dotnet/templating#2429

Closed

6 tasks

marcpopMSFT mentioned this pull request Aug 12, 2020

Finish optional SDK workload composition dotnet/sdk#12901

Closed

6 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

.NET SDK workloads overview spec #100

.NET SDK workloads overview spec #100

richlander commented Mar 24, 2020 •

edited

Loading

KathleenDollard left a comment

stevenbrix Mar 26, 2020 •

edited

Loading

richlander Apr 8, 2020

Nirmal4G commented Apr 6, 2020

richlander commented Apr 8, 2020

richlander commented Apr 8, 2020

Nirmal4G commented Apr 8, 2020

stephentoub Apr 8, 2020

stephentoub Apr 8, 2020

richlander Apr 8, 2020


		### SDK and workload versioning

		Another benefit of the existing monolithic SDK is that the workloads it includes are known to be compatible with core SDK components, like the C# compiler, NuGet, MSBuild, and the SDK targets. Over time, we have developed the concept of an SDK version train. These are represented by SDK version hundreds bands like `3.1.100` and `3.1.200`. These version trains were created to align with Visual Studio versions, like `16.4` and `16.5`. We do this because those same core SDK components are shared between Visual Studio and the .NET SDK, and need to stay in alignment. In addition, new major versions of those components, possibly containing a new language version, can be delivered in these updates. 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.

		@@ -0,0 +1,97 @@
		# .NET Optional SDK Workloads

		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.

.NET SDK workloads overview spec #100

.NET SDK workloads overview spec #100

Conversation

richlander commented Mar 24, 2020 • edited Loading

KathleenDollard left a comment

Choose a reason for hiding this comment

stevenbrix Mar 26, 2020 • edited Loading

Choose a reason for hiding this comment

richlander Apr 8, 2020

Choose a reason for hiding this comment

Nirmal4G commented Apr 6, 2020

richlander commented Apr 8, 2020

richlander commented Apr 8, 2020

Nirmal4G commented Apr 8, 2020

stephentoub Apr 8, 2020

Choose a reason for hiding this comment

stephentoub Apr 8, 2020

Choose a reason for hiding this comment

richlander Apr 8, 2020

Choose a reason for hiding this comment

richlander commented Mar 24, 2020 •

edited

Loading

stevenbrix Mar 26, 2020 •

edited

Loading