Remove env var workaround that causes dotnet to use MSBuild out-of-proc

[baronfel]

Per the comment, to work around dotnet/runtime#50554 the CLI would silently shift to out-of-proc mode.

However, this issue was addressed in .NET 8, so we can remove the workaround in the dotnet CLI since main always runs on 10+ runtimes.

[Copilot]

Pull Request Overview

Removes the legacy workaround that forced MSBuild to run out-of-proc when environment variables were empty or contained a null character, since this issue is fixed in .NET 8 and the CLI now targets runtimes 10+.

• Deletes the if (value == string.Empty || value == "\0") block and related fallback calls in EnvironmentVariable
• Simplifies the MSBuild forwarding code by assuming in-proc support for empty env values

Comments suppressed due to low confidence (1)

src/Cli/Microsoft.DotNet.Cli.Utils/MSBuildForwardingAppWithoutLogging.cs:114

• [nitpick] Consider adding a comment here explaining that the out-of-proc fallback for empty or '\0' environment values has been removed because the underlying runtime issue is fixed in .NET 8, to guide future maintainers.

    public void EnvironmentVariable(string name, string value)

[Copilot]

The removal of the fallback for empty or null-character environment values changes behavior for those inputs; please add or update tests to cover setting environment variables with an empty string or '\0' to ensure correct in-proc behavior on .NET 8+.

[dsplaisted]

Should we have any tests for this? Was there a scenario to verify manually?

[baronfel]

@dsplaisted that's part of why I sent the PR - to see if CI had any test cases that would fail :D I suppose I can make a test app that echos a specific environment variable, and then try to trigger that?