Description
Is your feature request related to a problem? Please describe.
If a .NET tool does not allow major-version runtime roll forward and is run without any of the runtimes that it targets, it will fail. I would like a dotnet command-line option that overrides this setting.
Describe the solution you'd like
Allow runtime-options in dotnet commands that run local tools. For example, dotnet --fx-version 6.0.7 sarif or dotnet tool run --roll-forward Major sarif.
A similar effect can already be achieved by setting the DOTNET_ROLL_FORWARD environment variable, which works with both global and local tools, as well as other .NET applications. However, that would be inherited by child processes too, unlike the command-line option. Inheritance is a good thing if the child process runs an executable that belongs to the same tool, but perhaps not if the child process runs an executable whose path the user specifies as an argument of the tool.
Additional context
sarif in the previous examples refers to Sarif.Multitool 2.4.16, which does not allow major-version runtime roll forward. I filed microsoft/sarif-sdk#2511 about fixing it. #26417 (comment) suggests a build warning for tools like that.
If a future version of .NET SDK allows an unmanaged executable to be packaged and run as a .NET tool (i.e. without Command/@Runner="dotnet" in DotnetToolSettings.xml), then it will not be possible to support runtime-options for that.
This is starting to look like a bad idea overall.