Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add link to new workload set documentation #9483

Merged
merged 5 commits into from
Oct 23, 2024
Merged

Add link to new workload set documentation #9483

Changes from all commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
246dc64
Add link to new workload set documentation
tdykstra Aug 24, 2024
b880087
Update release-notes/9.0/preview/preview7/sdk.md
tdykstra Oct 22, 2024
ffadb9e
Fix for Markdownlint errors from preexisting text.
tdykstra Oct 22, 2024
cc95e37
Merge branch 'main' into tdykstra-patch-1
tdykstra Oct 22, 2024
5e54661
Fix line length Markdownlint error
tdykstra Oct 22, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
23 changes: 13 additions & 10 deletions release-notes/9.0/preview/preview7/sdk.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -37,34 +37,38 @@ Requirements (depending on your environment):
## More consistent environment variables for container publishing

[@kasperk81](https://github.com/kasperk81) noticed that the environment variables that the container publish tooling use to control some of the finer aspects of registry communication and security were not aligned with the existing conventions.
Most of the rest of the CLI uses the `DOTNET` 'namespace' for environment variables, but the container tooling used `SDK` instead. They helpfully [unified our environment variables to the `DOTNET` version](https://github.com/dotnet/sdk/pull/41769), while keeping support for the older `SDK` prefix. Going forward, please use the `DOTNET` prefix for environment variables, as we will eventually deprecate the older form.
Most of the rest of the CLI uses the `DOTNET` 'namespace' for environment variables, but the container tooling used `SDK` instead.
They helpfully [unified our environment variables to the `DOTNET` version](https://github.com/dotnet/sdk/pull/41769), while keeping support for the older `SDK` prefix.
Going forward, please use the `DOTNET` prefix for environment variables, as we will eventually deprecate the older form.

## Introduction of Workload Sets for more control over workloads

This preview is the first release of Workload Sets - an SDK feature intended to give users more control over the workloads they install and the cadence of change of those installed workloads. Prior to this release, workloads would periodically be updated as new versions of individual workloads were released onto any configured NuGet feeds. Now, after switching to this new opt-in mode of operation, users will stay at a specific single version of all of their workloads until they make an explicit update gesture.
This preview is the first release of Workload Sets - an SDK feature intended to give users more control over the workloads they install and the cadence of change of those installed workloads.
Prior to this release, workloads would periodically be updated as new versions of individual workloads were released onto any configured NuGet feeds.
Now, after switching to this new opt-in mode of operation, users will stay at a specific single version of all of their workloads until they make an explicit update gesture.

You can see what mode your SDK installation is in by running `dotnet workload --info`:

```terminal
> dotnet workload --info
Workload version: 9.0.100-manifests.400dd185
Workload version: 9.0.100-preview.7.24414.1
Configured to use loose manifests when installing new manifests.
[aspire]
Installation Source: VS 17.10.35027.167, VS 17.11.35111.106
Manifest Version: 8.0.2/8.0.100
Manifest Path: C:\Program Files\dotnet\sdk-manifests\8.0.100\microsoft.net.sdk.aspire\8.0.2\WorkloadManifest.json
Install Type: Msi
Installation Source: SDK 8.0.400
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is this a valid result for .NET 9 preview 7?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If the aspire workload was last installed when using 8.0.400-band SDKs, then yes - the next time a workload update happened (via dotnet workload install or dotnet workload update) I'd expect this to change to align with the in-use SDK's feature band.

Manifest Version: 8.1.0/8.0.100
Manifest Path: C:\Program Files\dotnet\sdk-manifests\8.0.100\microsoft.net.sdk.aspire\8.1.0\WorkloadManifest.json
Install Type: FileBased
```

In this example, I am in 'manifest' mode, which is what we call the current mode of managing workloads.
This example uses the 'manifests' mode, which is what we call the current mode of managing workloads.
The simplest way to opt into the new mode is to add a `--version` option to a `dotnet workload install` or `dotnet workload update` command, but you can also explicitly control your mode of operation using the new `dotnet workload config` command:

```terminal
> dotnet workload config --update-mode workload-set
Successfully updated workload install mode to use workload-set.
```

If you need to change back for any reason, you can run the same command with `manifests` instead of `workload-set`. You can also use `dotnet workload config --update-mode` to check what the current mode of operation is. You can read more about workload sets in [our documentation]().
If you need to change back for any reason, you can run the same command with `manifests` instead of `workload-set`. You can also use `dotnet workload config --update-mode` to check what the current mode of operation is. You can read more about workload sets in [our documentation](https://learn.microsoft.com/dotnet/core/tools/dotnet-workload-sets).

## Mitigating analyzer mismatch issues aka 'torn SDK'

Expand All @@ -85,4 +89,3 @@ You can read more about it [in our documentation for the effort](https://github.
In short, the SDK's MSBuild logic embeds the version of MSBuild it shipped with, and we can use that information to detect when the SDK is running in an environment other than that version.

When we detect this, the SDK inserts an implicit [PackageDownload](https://learn.microsoft.com/nuget/consume-packages/packagedownload-functionality) of a support package called `Microsoft.Net.Sdk.Compilers.Toolset` that ensures a consistent analyzer experience for users.

Loading