[release/11.0.1xx-preview7] Honor Configuration environment variable in CLI options

[github-actions]

Backport of #55431 to release/11.0.1xx-preview7

/cc @Evangelink

[azure-pipelines]

Azure Pipelines:
Successfully started running 1 pipeline(s).
2 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[Youssef1313]

What if I have the following setup?

1. Configuration env variable set to Release.
2. Solution with two projects:
   • ProjectA: Typical project like the template console app.
   • ProjectB: It has explicit <Configuration>Debug</Configuration>

Are we introducing a behavior change for ProjectB before vs after this change?

[baronfel]

B never used Configuration in that case I believe - the environment variable would already override, because MSBuild read it from the env var.

[Evangelink]

Thank you both. Resolving the thread

[Youssef1313]

@baronfel I tested on this csproj:

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net11.0</TargetFramework>
    <ImplicitUsings>enable</ImplicitUsings>
    <Nullable>enable</Nullable>
    <Configuration>Debug</Configuration>
  </PropertyGroup>

</Project>

On current SDK without this PR:

It looks like Configuration from csproj is winning (Note that I'm building csproj right away, the behavior is likely to be different when dealing with solution).

The change in this PR will make the same scenario use Release instead of Debug.

[Evangelink]

/ba-g

PR #55452 is a backport that only touches CLI option definitions: CommonOptions.cs, HelpBuilder.cs, and their tests (CliSchemaTests.cs, CommonOptionsTests.cs, a dotnet test options test). It does not touch the file-based-app / run-file feature at all.

The build failed on 2 Helix work items (exit code 2), with these failures:

1. FullFramework windows — It_generates_satellite_assemblies

Console-encoding issue: expected Bienvenue à .Net! but stdout rendered it as Bienvenue à .Net!. A code-page/locale artifact on the test agent. Unrelated to the PR.

2. dotnet.Tests windows — 8 failures, all in RunFileTests_BuildOptions

(WorkingDirectory, WorkingDirectory_CscOnly_AfterMSBuild, BinaryLog_EvaluationData_MultiFile, Verbosity_CompilationDiagnostics, MissingShebangWarning ×3, EmbeddedResource)

The error signatures all point to the run-file build cache returning stale/wrong output:

• expected v2 but got v1 / old content

• expected MSBuild will be skipped… but got build will be skipped because output is up to date

• expected warning CA2266 / embedded resource, got plain hello / Resource not found

• Exit Code: 0 where the test expected a rebuild or failure

This is a test-isolation/caching flakiness pattern in file-based apps, with an established history in the repo (e.g. #54813 "Flaky: RunFileTests_* intermittently fail", #54819, #55057 "handle deleted artifacts directory"). None of it exercises the CLI option code the PR modifies.