[enhancement]: improve .NET version selection

[CaringDev]

Task name

UseDotNet@2

Describe your feature request here

In #21860 the .NET version selection changed to always use the latest allowed one. Now, under the following conditions

• useGlobalJson
• global.json with rollForward != disable
• VS (that is, not installing SDKs separately)
• lock files packages.lock.json
• solutions containing projects that reference SDK-version dependent (implicit) packages

this poses an issue when a new patch version is released which is not yet published with VS.
E.g. we set our global.json to latest SDK included with VS (10.0.202) and an update (10.0.203) gets released.
Also: we want useGlobalJson to minimize version mismatches / edits when updating.
Also: we use lock-files for improved traceability and security.
Also: we use rollForward: latestPatch to allow devs to update their installations without immediately updating the projects.
Also: we do not want to manage SDKs manually, i.e. we rely on VS Installer

Now the build fails because in the CI pipeline run e.g. Microsoft.NET.ILLink.Tasks gets updated from 10.0.6 to 10.0.7

Proposed solution: change the version resolution logic s.t. if rollFoward is set to non-latest values, i.e. patch / feature / major / minor the lowest matching version is selected, keep current behavior for latest*.

Note that at the time of writing, ADO images contain 10.0.202 but even specifying checkForExistingVersion does not help.

[Frulfump]

Hmm unsure if you can get all that you want here.

Microsoft recommends using rollForward = disable when using lock-files at least right now due to packages like Microsoft.NET.ILLink.Tasks (related issue dotnet/sdk#48795) and Microsoft.AspNetCore.App.Internal.Assets (related issue dotnet/aspnetcore#65061)
see comment from Microsoft here dotnet/sdk#48795 (comment)

Our current recommendation for users that use lock files is to also lock their SDK versions via global.json with no rollforward, so they(sic) their entire toolchain stays in lockstep.

I have similar needs to you but we chose to set rollForward = disable

[CaringDev]

Hmm unsure if you can get all that you want here.

Hmm, in general, sure, not 🤷
Here, yes, I could... only question is whether MS will allow me to have my cake and let me eat it, too 😆

With all due respect for the recommendations... the proposed solution would enable a "good-practice workflow" and unlock valueable benefits. Frankly, IMO, such recommendations are counterproductive and dangerous. If, at all, they should be presented as a last-resort workaround.

If we recommend to lock the full toolstack, we require teams working on multiple solutions / projects to either / combination of:

• update all tooling / projects in sync
• manage SDKs manually
• keep insecure SDKs
• not use lockfiles

each with major drawbacks.
E.g. we can't keep old SDKs around, as company policy (with good reasons) forces us to update / remove (by means of intrusive endpoint management software) all locally installed software.
Encouraging software development without lockfiles is IMO a no-go. Supply chain attacks are a real risk and we (as SW industry) should strive to reap every little security gain whenever and wherever possible.

we chose to set rollForward = disable

That's our solution too, for now. I'm totally not happy though, for the reasons given above.

[Frulfump]

Hehe yeah maybe, my worry is that it would assign special meaning for patch etc. and would bite someone in some other way that's not aware of the special casing. Agree on not removing lock files due to the reasons you mention.

Tools like Dependabot or Renovate help with keeping the SDK version updated but could be trickier with release-branches etc.

cc @baronfel hope you don't mind the ping here, how should we think here? It's another instance of global.json created for usage with .NET itself (and already installed versions on a machine) and downstream "applications" assigning other meaning to the file than what was initially intended?

[CaringDev]

... special meaning for patch ...

IMO that is the intended meaning (emphasis mine):

Uses the specified version. If not found, rolls forward to the latest patch level.

Whereas latestPatch:

Uses the latest installed patch level that matches the requested major, minor, and feature band with a patch level that's greater than or equal to the specified value.

In combination with checkForExistingVersion this would enhance predictability and (potentially, left to be decided there whether a already-installed matching version < available matching version is OK) speed of builds.

[Frulfump]

... special meaning for patch ...

IMO that is the intended meaning (emphasis mine):

Uses the specified version. If not found, rolls forward to the latest patch level.

Whereas latestPatch:

Uses the latest installed patch level that matches the requested major, minor, and feature band with a patch level that's greater than or equal to the specified value.

In combination with checkForExistingVersion this would enhance predictability and (potentially, left to be decided there whether a already-installed matching version < available matching version is OK) speed of builds.

The problem is that global.json is meant to deal with already installed versions on a machine (as evident by "Uses the _latest installed patch level" and "If not found," meaning found (installed) on the machine) and the UseDotNet@2 task uses the file to "guess" what it should install.

So a question is should there be yet another option in UseDotNet to tell it how to interpret global.json? Or should the current behavior change? I'd argue that currently the task is working as intended (if that intention is good or bad is yet another question/consideration)

The task option for useGlobalJson itself is really thin (essentialy just "Installs all SDKs from global.json files" and to see the official global.json docs for more info)
https://learn.microsoft.com/en-us/azure/devops/pipelines/tasks/reference/use-dotnet-v2?view=azure-pipelines#inputs

useGlobalJson - Use global json
boolean. Optional. Use when packageType = sdk. Default value: false.

Installs all SDKs from global.json files. These files are searched from system.DefaultWorkingDirectory. You can change the search root path by setting the working directory input.

The 6.x and 6.1.x format (using .x as a wildcard) described in the UseDotNet@2.version input is for use in the version input in the task, not the sdk.version parameter in global.json.

If you receive an error message like ##[error]Version 6.0.x is not allowed. Allowed version types are: majorVersion.x, majorVersion.minorVersion.x, majorVersion.minorVersion.patchVersion. More details: Only explicit versions and accepted, such as: 2.2.301. Version: 6.0.x is not valid. and you are using global.json, check the sdk.version in your global.json.

For more information on global.json, see Select the .NET version to use.

[CaringDev]

If I could redesign the feature from start (v3 anyone?), useGlobalJson would be the default (as it is for https://github.com/actions/setup-dotnet, which has similar issues) and the task would honor rollForward similar to how NuGet honors DependencyVersion Whether the default should be pessimistic (min) or optimistic (max) is left for discussion.

Or we'd introduce an (optional) lockfile for the SDK and the task would honor that, lokal install would overwrite (by default), just as it is the case with NuGet (tools), (p)npm, ...