Enable multithreaded MSBuild in acceptance tests

[Amaury Levé (Evangelink)]

Summary

• enable multithreaded MSBuild for ordinary acceptance-test dotnet build calls with -mt
• enable the equivalent mode for project-based dotnet test through MSBUILDENABLEMULTITHREADED=1
• opt out browser-WASM builds and MSBuild Test target scenarios whose tasks do not support multithreaded execution yet
• leave assembly-based dotnet test execution unchanged because it bypasses MSBuild

Local performance report

Environment: Windows 11 Enterprise 10.0.26200; AMD Ryzen AI Max+ 395 (16 cores/32 logical processors); 47.8 GB RAM; .NET SDK 11.0.100-rc.2.26425.121; MSBuild 18.11.0.42621.

The benchmark used generated, multi-targeted MSTest acceptance assets (net10.0, net8.0, and net462). Acceptance tests ran with 32 method-level workers and a fresh randomized NuGet package directory per test-assembly invocation.

Benchmark scenario	Without multithreaded MSBuild	With multithreaded MSBuild	Change
Four-case scenario, median of 3	19.421s	17.874s	8.0% faster
Broader 32-case scenario	2m 30.221s	1m 42.742s	31.6% faster

Four-case samples were 19.420s, 20.570s, and 13.990s without multithreading versus 18.210s, 17.320s, and 17.870s with multithreading. All measured tests passed. The smaller sample is noisy, but both scenarios showed improvement and the larger concurrent scenario showed the strongest gain.

Integration findings

The Microsoft.Testing.Platform mode of dotnet test does not accept the raw MSBuild -mt switch; it treats it as an unmatched platform option and test applications fail their handshake. This change therefore passes -mt directly to dotnet build, while project-based dotnet test uses MSBuild's equivalent MSBUILDENABLEMULTITHREADED=1 environment input.

Two task paths currently need explicit opt-outs:

• The browser-WASM SDK's JsonToItemsTaskFactory cannot run in the out-of-process TaskHost selected by -mt.
• InvokeTestingPlatformTask does not yet preserve its terminal summary and output artifacts in that TaskHost, so acceptance scenarios that directly exercise build -t:Test remain single-process.

Validation

• build.cmd -pack -bl
• targeted four-case scenario, three runs per variant
• broader 32-case acceptance scenario
• all 52 MTP acceptance cases covering the failed build -t:Test matrix and browser-WASM build
• 8 MSBuild solution acceptance cases
• 12 MSTest acceptance cases covering MSBuild Test target opt-outs and ordinary multithreaded build/test paths

[Copilot]

Copilot review overview

🟢 Approval recommended

The command classification and multithreading configuration correctly match the documented execution modes.

Review tier: Balanced
Findings: None

What changed in this PR

Enables multithreaded MSBuild for MTP and MSTest acceptance-test invocations.

Changes:

• Adds opt-in multithreading for dotnet build and project-based dotnet test.
• Excludes assembly-based test execution.

File	Description
DotnetCli.cs	Detects MSBuild-backed commands and configures multithreading.
AcceptanceFixture.cs	Enables the behavior for both linked acceptance suites.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Copilot]

Copilot review overview

🟡 Changes recommended

Explicit opt-outs can be defeated by inherited environment variables, and project-based tests can be misclassified as assembly-based.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Review tier: Balanced
Findings: 2

New issues introduced by this change (2)

Severity	Finding
	test/​Utilities/​Microsoft.Testing.TestInfrastructure/​DotnetCli.cs — The per-call opt-outs are not deterministic because RunAsync first copies the parent environment.…
	test/​Utilities/​Microsoft.Testing.TestInfrastructure/​DotnetCli.cs — This classifies a test as assembly-based when .dll or .exe occurs anywhere in the command line,…

[Copilot]

Copilot review overview

🟡 Changes recommended

Direct --test-modules invocations can be misclassified and receive unsupported MSBuild arguments.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Review tier: Balanced
Findings: 1

New issues introduced by this change (1)

Severity	Finding
	test/​Utilities/​Microsoft.Testing.TestInfrastructure/​DotnetCli.cs — --test-modules is also a direct-module selector and bypasses MSBuild (see…

Issues resolved since last review (2)

Severity	Finding
	test/​Utilities/​Microsoft.Testing.TestInfrastructure/​DotnetCli.cs — This classifies a test as assembly-based when .dll or .exe occurs anywhere in the command line,… View resolved comment
	test/​Utilities/​Microsoft.Testing.TestInfrastructure/​DotnetCli.cs — The per-call opt-outs are not deterministic because RunAsync first copies the parent environment.… View resolved comment

[Copilot]

Copilot review overview

🟡 Changes recommended

Optional --list-tests parsing can skip a following --test-modules selector and misclassify direct test execution.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Review tier: Balanced
Findings: 1

New issues introduced by this change (1)

Severity	Finding
	test/​Utilities/​Microsoft.Testing.TestInfrastructure/​DotnetCli.cs — --list-tests has optional arity, but this unconditional skip treats the next option as its value.…

Issues resolved since last review (1)

Severity	Finding
	test/​Utilities/​Microsoft.Testing.TestInfrastructure/​DotnetCli.cs — --test-modules is also a direct-module selector and bypasses MSBuild (see… View resolved comment

[Copilot]

Copilot review overview

🔵 Needs a closer look

Direct test invocations can be misclassified because the value-taking option table omits valid options.

Review tier: Balanced
Findings: None

Issues resolved since last review (1)

Severity	Finding
	test/​Utilities/​Microsoft.Testing.TestInfrastructure/​DotnetCli.cs — --list-tests has optional arity, but this unconditional skip treats the next option as its value.… View resolved comment

Suppressed comments (1)

Previously missed (1) — in code that hasn't changed since the last review.

test/Utilities/Microsoft.Testing.TestInfrastructure/DotnetCli.cs:10

• The value-taking option table is incomplete: valid options such as --verbosity and --blame-hang-dump-type are omitted. For example, test --verbosity normal MyTests.dll treats normal as the positional target, returns false before reaching the DLL, and then adds multithreaded-MSBuild state plus an MSBuild binlog to a direct test invocation. Please add the missing aliases (with parser tests), or make detection continue past unrecognized option values safely.

[Copilot]

Copilot review overview

🟢 Approval recommended

The implementation correctly distinguishes supported invocations and includes targeted opt-outs for known incompatible task paths.

Review tier: Balanced
Findings: None