Skip to content
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

Closed
KalleOlaviNiemitalo opened this issue Jul 27, 2022 · 4 comments
Closed

runtime-options (--roll-forward) for local tools #26824

KalleOlaviNiemitalo opened this issue Jul 27, 2022 · 4 comments
Milestone

Comments

@KalleOlaviNiemitalo
Copy link
Contributor

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.

@dotnet-issue-labeler dotnet-issue-labeler bot added Area-Tools untriaged Request triage from a team member labels Jul 27, 2022
@baronfel
Copy link
Member

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.

@baronfel baronfel removed the untriaged Request triage from a team member label Jan 10, 2023
@baronfel baronfel added this to the 8.0.1xx milestone Jan 10, 2023
@baronfel
Copy link
Member

baronfel commented Feb 3, 2023

System.CommandLine also hit this with their dotnet-suggest tool, as logged in dotnet/command-line-api#2014

@marcpopMSFT
Copy link
Member

Rather than default to rollforward like #30336 says, we plan on adding an option so it allows opting in at install time.

@JL03-Yue
Copy link
Member

JL03-Yue commented Apr 4, 2024

Close as merged in #37231

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants