Allow the --roll-forward switch to be used with local tools

The runtime-option --roll-forward is settable when using the exec SDK command but currently not when invoking a repo tool with dotnet tool run. If a repo tool doesn’t define a roll-forward policy then there’s no way to make a tool run on a higher shared framework version.

I’m not up-to-date on the decisions being made around repo tools but naively I would expect that option to be usable with repo tools.

cc @KathleenDollard @vitek-karas @wli3

[vitek-karas]

You can set the roll-forward option via env. variable DOTNET_ROLL_FORWARD, it’s not exactly convenient but might be useful as a workaround. Note that the env. variable will override whatever the tool has in its config file.

There are two settings which apply to this scenario:

• Major - which will roll forward to the closest available version including another major version. So if the tool asks for 2.1 and there’s 3.1 and 6 on the machine, it will use 3.1 (since it’s closer than 6).
• LatestMajor - which will roll forward to the highest version available, so if the tool asks for 2.1 and there’s 3.1 and 6 on the machine, it will use 6.

Original design: https://github.com/dotnet/designs/blob/main/accepted/2019/runtime-binding.md#configuration-knobs Technical design doc: https://github.com/dotnet/runtime/blob/main/docs/design/features/framework-version-resolution.md#roll-forward

[richlander]

I’m glad we have the ENVs. We should also allow roll-forward via the CLI.

@baronfel