-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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.
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
runtime-options (--roll-forward) for local tools #26824
Comments
This is something we should do - I think tools are a strong case for a default rollforward policy of latestmajor (I've added this to at least 5 tools myself over the 6-to-7 release), but at minimum tools should support the flag the same way that 'raw' dotnet dll invocations do. |
System.CommandLine also hit this with their dotnet-suggest tool, as logged in dotnet/command-line-api#2014 |
Rather than default to rollforward like #30336 says, we plan on adding an option so it allows opting in at install time. |
Close as merged in #37231 |
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
ordotnet 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"
inDotnetToolSettings.xml
), then it will not be possible to support runtime-options for that.This is starting to look like a bad idea overall.
The text was updated successfully, but these errors were encountered: