Add optional workload folders #27357
Conversation
dsplaisted
left a comment
dsplaisted
left a comment
There was a problem hiding this comment.
FYI, you can refer to dotnet/designs#188 for a lot of the detailed design behind this, although it may not be entirely up to date.
docs/core/distribution-packaging.md
Outdated
| │ └── NuGetFallbackFolder (4) (*) | ||
| │ └── <sdk version> (3) | ||
| ├── sdk-manifests (4) (*) | ||
| │ └── <sdk version> |
There was a problem hiding this comment.
This folder isn't exactly the SDK version. It is the feature band version. So for an SDK version such as 6.0.102, this folder would still be versioned at 6.0.100.
docs/core/distribution-packaging.md
Outdated
| - (3) **sdk/\<sdk version>** The SDK (also known as "the tooling") is a set of managed tools that are used to write and build .NET libraries and applications. The SDK includes the .NET CLI, the managed languages compilers, MSBuild, and associated build tasks and targets, NuGet, new project templates, and so on. | ||
|
|
||
| - (4) **sdk/NuGetFallbackFolder** contains a cache of NuGet packages used by an SDK during the restore operation, such as when running `dotnet restore` or `dotnet build`. This folder is only used prior to .NET Core 3.0. It can't be built from source, because it contains prebuilt binary assets from `nuget.org`. | ||
| - (4) **sdk-manifests/\<sdk version>** The names and versions of the assets that an optional workload installation requires are maintained in [advertising manifests](tools/dotnet-workload-install.md#advertising-manifests) stored in this folder. When a workload is installed, the following folders are created as needed for the workload's assets: a *library-packs* folder, a *metadata* folder, and a *template-packs* folder. Include these folders if you want to install a workload and distribute the SDK with the workload included. |
There was a problem hiding this comment.
These are not advertising manifests. They are just workload manifests.
The advertising manifests are stored outside of the dotnet root and represent updates that are available to the workload manifests, but which haven't been installed. The contents / format of the advertising manifests are the same, though. I don't think this document needs to mention advertising manifests at all.
I would also probably remove this whole part, because if people do want to create a distribution of the SDK with the workload already installed, it's going to take more documentation than what is covered here:
When a workload is installed, the following folders are created as needed for the workload's assets: a library-packs folder, a metadata folder, and a template-packs folder. Include these folders if you want to install a workload and distribute the SDK with the workload included.
There was a problem hiding this comment.
I assume we should remove mention of these from the diagram above also, then. Or remove only the sentence about distributing the SDK with installed workload.
There was a problem hiding this comment.
That's probably a good idea, although we could also mention that a distribution can lay down an empty /metadata/workloads/<sdkfeatureband>/userlocal file if workloads should be installed under a user path rather than in the dotnet folder.
See dotnet/sdk#18823 and dotnet/installer#12021.
There was a problem hiding this comment.
we could also mention that a distribution can lay down an empty /metadata/workloads//userlocal file if workloads should be installed under a user path rather than in the dotnet folder.
Yes, we should include this.
|
@omajid can you take a look at this, and maybe provide some feedback based on how we're packaging these things up? |
Co-authored-by: Daniel Plaisted <[email protected]>
BillWagner
left a comment
BillWagner
left a comment
There was a problem hiding this comment.
This LGTM @tdykstra
When you and the product team are satisfied, you can 
|
@omajid do you have any feedback? |
5 participants
Fixes #26901