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

[baronfel]

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

• runtime-options (--roll-forward) for local tools #26824
• dotnet-suggest not available for .net 7 command-line-api#2014
• add rollforward policy to next-major fsprojects/FAKE#2372
• https://github.com/cake-build/cake/blob/develop/src/Shared.msbuild#L4
• Replace rollForward in tools runtimeconfig #24817
  • existing SDK tools ship Major/LatestMajor already - evidence for the pattern being useful more widely
• EF also moved to a more aggressive rollforward: Update tool to roll forward to latest major version of runtime installed. efcore#27671

[baronfel]

Pinging @richlander and @vitek-karas because this behavior change would technically limit the flexibility of the runtime to make breaking changes.

[vitek-karas]

I think it would be really unfortunate if this caused use to change the bar on breaking changes in .NET (it doesn't feel important enough to do that). So far we've been pretty specific about developers making an explicit decision to roll forward over major versions.

That said I agree that for the tools this makes a lot of sense. I think we should be very explicit about this - meaning that installing the tool will "force roll-forward" and what are the ways for tool's developers to avoid that. Basically still trying to keep our existing major version compatibility stance, and .NET tools would be an explicit exception to the rule - where developing a tool is in itself an opt-in to this behavioral change.

[richlander]

This other proposal is getting at much of the same thing, but in a different way. I'd rather see us focus on making it easier to move projects forward to new .NET versions. I think this other proposal has less of the issues that Vitek is concerned about.

• Enable projects to use the SDK TargetFramework #29949

I also agree that changing our roll-forward policy (for any binaries) is going to cause us pain. I think it is good we have an opt-in, for both producer and consumer of code.

[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)

#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.

[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.

[richlander]

You are right @vitek-karas. The thing I'm getting at doesn't solve the problem. However, one of the reasons why some people have pushed back on my proposal is compatibility. If we cannot enable an easier source upgrade option, then binary roll-forward is off the table. The two options are on a compatibility spectrum.