Broken Test output when specifying `-tl:off` in `Directory.Build.rsp`

[ericstj]

Describe the bug

MSBuild supports a Directory.Build.rsp convention for adding properties to MSBuild.

When using this to specify -tl:off it works for most cases, except for dotnet test. In that case only part of the test output is seen (only for a single target framework of a multi-targeted project).

This has been impacting dotnet/runtime for some time. It would be nice to have a happy path for folks running tests in our repo. Either with the terminal logger or without. See dotnet/runtime#94183

To Reproduce

Create a test project that multi-targets.
Add a Directory.Build.rsp with -tl:off
run dotnet test on the project.

xunitTest.zip

Exceptions (if any)

None

Further technical details

Issue appears to be here --

sdk/src/Cli/dotnet/Commands/Test/TestCommand.cs

Line 102 in 55044e9

additionalBuildProperties = ["--property:VsTestUseMSBuildOutput=true"];

To fix it, I think the SDK would need to crack the RSP.

I tried to workaround it by also specifying VsTestUseMSBuildOutput=false in the RSP but this is ignored (rightly) since MSBuild prioritizes the command line arguments over the RSP. I also tried to specify in a props with TreatAsLocal, but it didn't seem to help. I did find that specifying /p:VsTestUseMSBuildOutput=true on the commandline (with RSP in place) would work, and behave similarly to /tl:off on the commandline, so that makes me wonder if

sdk/src/Cli/dotnet/Commands/Test/TestCommand.cs

Lines 117 to 125 in 55044e9

	static string[] SetLegacyVSTestWorkarounds(string NodeWindowEnvironmentName)
	{
	string[] additionalBuildProperties;
	// User explicitly disabled the new logger. Use workarounds needed for old logger.
	// Workaround for https://github.com/Microsoft/vstest/issues/1503
	Environment.SetEnvironmentVariable(NodeWindowEnvironmentName, "1");
	additionalBuildProperties = ["-nodereuse:false"];
	return additionalBuildProperties;
	}

is still needed.

I do see that microsoft/vstest#1503 is resolved, so maybe SDK can just delete this workaround?

@nohwnd @baronfel