[Proposal] .NET Tools should default to running on the latest available Runtime

Is your feature request related to a problem? Please describe.

Currently, .NET applications use a runtimeConfig to determine which runtime they run on. This is something that is determined at build time, but non-tool .NET applications can override this with various flags and environment variables given to the .NET runtime host. The default rollforward policy is LatestPatch, which allows an application to run on any runtime of the same major/minor version that is at least as high a version as the application was built against.

.NET (local) Tools are a specific kind of .NET application that are intended to be distributed and managed via SDK commands. They are generally development tools/utilities. We think the semantics of tools are such that tools should be able to run on any .NET runtime equal or greater than the runtime the application originally targeted. This will reduce friction for users adopting new SDKS/Runtimes by not completely blocking their workflows without some explicit proof on incompatibility.

Without this change, tool authors must either explicitly set a more flexible roll-forward policy, or multitarget. Multitargeting has the side effect of increasing the overall size of the tool, and still not solving the issue - a tool that multitargets net6.0 and net7.0 will still not run on net8.0 runtimes.

Describe the solution you’d like

There are two places we could address this mismatch:

• build time, when a tool’s RollForward defaults are baked into the resulting application
• install time, when any apphosts/runtimeConfigs are authored by the SDK for subsequent executions

Build Time changes

We would change the RollForward of all tools from LatestPatch to LatestMajor. This would cause the desired behavior for all newly-built apps. We would also track a sentinel value that we set the RollForward, so that at install time we could tell if the user explicitly requested a change to the RollForward.

Install Time changes

We would ensure that tools that did not explicitly override to force a certain RollForward behavior would be written with LatestMajor behavior. This helps us plug the existing behavior gap for tools that haven’t been authored with an SDK containing these changes.

Additional context

• https://github.com/dotnet/sdk/issues/26824
• https://github.com/dotnet/command-line-api/issues/2014
• https://github.com/fsprojects/FAKE/pull/2372
• https://github.com/cake-build/cake/blob/develop/src/Shared.msbuild#L4
• https://github.com/dotnet/sdk/pull/24817
  • existing SDK tools ship Major/LatestMajor already - evidence for the pattern being useful more widely
• EF also moved to a more aggressive rollforward: https://github.com/dotnet/efcore/pull/27671

[jander-msft]

As a single data point, if this automatic roll-forward was applied to .NET tools, the dotnet-monitor tool (which is an ASP.NET application that ships as a .NET tool) would likely opt-out of it. There was a change (I believe it was this) between .NET 6 and .NET 7 regarding the NTAuthentication class on which the Microsoft.AspNetCore.Authentication.Negotiate assembly used reflection to access internal APIs. It was changed in .NET 7 in such a way that the Negotiate assembly could no longer lookup the API it was attempting to reflect over. We had to disable roll-forward due to this change.

We’re okay with disabling roll-forward because we are actively working on dotnet-monitor and are releasing previews in lock-step with .NET 8 all up.

[vitek-karas]

My understanding is that this issue is trying to solve the problem that we have a slew of tools already on NuGet, but when we release 8.0 P1, only a few of them will work (those who added rollforward manually). I agree that it would be really nice to have a majority of the tools working from day 1 (especially since we rarely break people anymore). There’s also the fact that some tools are not maintained frequently so it may take a long time (if ever) to get them to run on 8.0)

https://github.com/dotnet/sdk/issues/29949 will only make it easier to test the update (note that I can’t publish the tool with that, since it would modify the min supported version). So the two are only related to the extent that latter makes it easier for people to test major versions.