Allow dotnet test command to override the Net runtime version

[RobSwDev]

I have a test assembly targetting Net6.0.
I want the option to execute the tests with dotnet test using a Net7.0 runtime, essentially overriding what the test's runtimeconfig.json file says.

Describe the solution you'd like

I can achieve this by updating the runtimeconfig.json, but this is a bit of a hack. (And my current version of PowerShell seems to mangle the json when using convertfrom-json, but that's a different issue)

I tried using the --framework option, but it gives a warning and won't override the runtimeconfig.

I could rebuild the test assembly with a different TargetFramework, but I'm trying to avoid this.

I'd like the --framework option to override anything specified in the runtimeconfig.json.
Alternatively, another mechanism to achieve the same ends.

Additional context

This may well be a crazy request.

Essentially, our product libraries target NetStandard2.0, and we want to test them on NetFramework and both Net6 & 7. We multi-target the tests to build "Net472;Net6.0". I want to avoid increasing the build time and size by adding a 3rd TargetFramework. Especially if we want to subsequently test Net8, etc.

[vitek-karas]

@MarcoRossignoli @richlander - as we've had discussions around similar topic

[nohwnd]

This is definitely not crazy request, but we've had a fair share of bugs related to similar functionality in .NET Framework, where we attempt to do pretty much this. So we would like to avoid implementing this. We can't know the content of your runtimeconfig.json and all the variations there, so modifying it on your behalf is quite difficult. Maybe runtimeconfig.dev.json could be provided on your behalf that modifies the original one, but then we risk that you already have one. And so on.

[vitek-karas]

There's one other way, but it may work for you:

• Install .NET 7 (or actually whatever target framework you want to test against) as a private install (so unpack the .zip download into a folder).
• Set it up - so set the PATH and DOTNET_ROOT env. variables.
• Set DOTNET_ROLL_FORWARD=Major
• Run

This should run the test on the 7.0 framework - and you don't need to change anything in the test itself (it should not even need to rebuild the test at all).

The downside of this approach is that it require the private install. There's no good way to force it to run on a specific version from the globally installed set - or it's not always reliable to do so. But for CI style testing this might work well enough.

[richlander]

Could --fx-version be used for this? It seems like dotnet test could expose this and pass this to the host.

[vitek-karas]

"Could"? - maybe
"Should"? - Definitely NO

The problem with --fx-version is that it applies to the first framework reference in the .runtimeconfig.json. There's no rule that Microsoft.NETCore.App has to be first...
So it's not a reliable mechanism.

The other downside is that it has to be the exact version - so if WU installs a new patch, the command line must change otherwise it won't run.

We don't have a reliable alternative to --fx-version... at least yet.

[richlander]

Got it. That's worse than I thought.

@elinor-fung