`dotnet run` should be able to default to a viable TFM when running a multi-targeted project

[baronfel]

Is your feature request related to a problem? Please describe.

Customers like Roslyn have many executable binary tools that they produce during their build. At the same time, they don't have explicit control over the TFM(s) that are used in their builds, due to source build, the VMR effort, and other cross-cutting infrastructure concerns. When executing these tools in scripts, the actual running TFM of the tool doesn't matter much to them, just that the application actually runs.

These users need an 'easy button' for dotnet run to make it easier to script. There should be an opt-in mode that picks the best relevant TFM from a project and uses it if there are multiple TFMs.

Describe the solution you'd like

dotnet run should have a flag similar in nature to --use-best-runtime. When specified, this flag would

• have no impact on a single-targeted project
• for a multi-targeted project, it would
  • grab the set of TFMs a project supports
  • choose the latest one that will run on the set of runtimes the currently-executing SDK has access too
  • continue run execution as if that framework had been chosen all along

[jaredpar]

What if instead dotnet run just implicitly chose the best runtime? Basically why not make dotnet run example.csproj just work except in cases where it simply cannot. For example there is no TFM in the project that can be resolved by the SDK. Outside that why not implicitly pick the best and use that one? For the set of customers who want to be explicit about the runtime they can use --framework as they do today.

The downside of having --use-best-runtime be explicit as that it could quickly lead to that being the idiomatic way for dotnet run to be used in non-trivial builds. Engineers on seeing a new dotnet run call could start rightfully pushing back saying

Please add --use-best-runtime so we don't have to clean this up later if we change that project to be multi-targeted.

It's certainly the approach I'd push for in roslyn because it's more correct for most build tooling. Build tooling generally doesn't care what runtime is being used, just that the tool is running on some compatible runtime.

Would be nicer if the idiomatic way remained simply dotnet run. That way the complexity of muli-targeting could largely stay in the build file.

[jaredpar]

Consider other parts of our tooling ecosystem that implicitly pick a target framework here:

• Visual Studio Debugging: When you F5 a project that is multi-targeted the first target framework will be chosen as the launch runtime.
• Visual Studio / VS Code Unit Testing: When using a right click menu to run / debug a test the first target framework will be chosen.

In both of these cases the environment simply picks the first target framework. There is no prompting or errors.

I think this also lets us side step the problem of finding the best runtime. Simply pick the first listed. It's the established precedent of our ecosystem.

[baronfel]

This is convincing to me. We can pick the first and have consistent behaviors across the ecosystem. I'm still unsure if we should log anything, but prior art from the -p flag quasi-deprecation suggests that we can emit warnings to stdout for dotnet run and folks will either address them or ignore them, as appropriate for their use case. It does hurt the scripting story for dotnet run from a stdin/stdout perspective, and is something we'd ideally clean up as part of our unified revamp of how we log CLI-specific messages/notifications/non-central-output to users.