Run wasm test hosts standalone under dotnet test (MTP)

[lewing]

Summary

Foundational SDK work for Blazor dotnet test support (#54091): run wasm test hosts (browser-wasm / wasi-wasm) under dotnet test and report their results, instead of crashing with PlatformNotSupportedException.

The exit-code path works on wasm today (validated end-to-end). The richer per-test TRX path is in place but gated off, pending a Microsoft.Testing.Extensions.TrxReport single-threaded-wasm fix — flipping one flag lights it up. Kept draft until that lands.

What it does

For wasm modules (detected via RunProperties.RuntimeIdentifier starting with browser/wasi):

• Skips MTP server mode (--server dotnettestcli --dotnet-test-pipe). wasm sandboxes can't open a named pipe, so testfx's DotnetTestConnection otherwise throws PlatformNotSupportedException at host build. The host now runs standalone and reports via process exit code.
• Reports pass/fail from the exit code (AssemblyRunStarted + AssemblyRunCompleted) — no per-test detail without a pipe or TRX, but correct assembly-level results.
• Does NOT emit --report-trx (see Known limitation). A WasmReportTrxSupported flag gates the TRX emission + results-directory defaulting; a nullable TRX path in ReportStandaloneResults distinguishes "TRX not requested → exit-code result" from "TRX requested but missing → crash".

The per-test TRX machinery (TrxTestResultParser + the TRX replay in ReportStandaloneResults) is retained as forward-looking: flipping WasmReportTrxSupported once TrxReport supports wasm enables full per-test reporting with no other change.

Validated end-to-end

Booting a real browser-wasm MSTest host (net10, MSTest 4.4.0-preview) under node:

Test run summary: Passed!
  total: 3, succeeded: 2, skipped: 1   ->  exit 0

The SDK↔bridge contract was also validated against the real Blazor Gateway (dotnet/aspnetcore) over real sockets + headless Chrome (serve, browser launch, console streaming, exit code).

Known limitation — TRX path gated off on wasm (why this stays draft)

--report-trx currently crashes a wasm host: TrxReport's TrxResultStreamingStore ctor starts a background Thread (SystemTask.RunLongRunning, [UnsupportedOSPlatform("browser")]), which throws PlatformNotSupportedException on single-threaded wasm (confirmed on MSTest 4.4.0-preview.26367.7 / MTP 2.4.0-preview.26367.7):

System.Threading.Thread.ThrowIfNoThreadStart
System.Threading.Thread.Start
Microsoft.Testing.Extensions.TrxReport.Abstractions.Streaming.TrxResultStreamingStore..ctor

The MTP owners (testfx) confirmed this is a real, previously-untested bug and are implementing an inline-writer fallback for single-threaded wasm on the browser-enablement track. Until that ships, emitting --report-trx would regress a wasm run that passes on its exit code, so this PR gates it off (WasmReportTrxSupported = false) and relies on the exit code. The Blazor Gateway's TRX-POST path is blocked by the same bug — a shared dependency.

When the TrxReport fix ships: flip WasmReportTrxSupported (or gate on a detected TrxReport version / host capability) and the full per-test TRX path activates.

Scoping findings for #54091

• A "properly configured" browser-wasm test project needs the net10-band wasm packs (the net11 preview.5 WasmGenerateAppBundle target is an empty stub), MSTest 4.4.0-preview+ (browser guards for the MSBuild + RunSettings host-controller extensions; 4.3.2 crashes), and a browser-compatible test registration. That configuration belongs in the Blazor/wasm test SDK or template, not the dotnet test CLI.
• The CLI change itself is TFM-agnostic and small.

Tests (all passing)

• TestApplicationTests — wasm RID detection; host-mode arg emission for standalone-with-TRX, standalone-without-TRX (neither server nor TRX), and non-standalone (server); results-directory defaulting.
• TrxTestResultParserTests — TRX parse, missing/malformed handling, outcome mapping.
• StandaloneTestResultReportingTests — TRX replay; missing-requested-TRX → handshake-failure (crash); no-TRX-requested → exit-code reporting (not a crash).
• Existing TestApplicationHandlerTests unaffected.

Notes

• User-visible: wasm test hosts run under dotnet test (exit-code results today; per-test TRX results once TrxReport supports wasm) instead of erroring with PlatformNotSupportedException.
• No change to any non-wasm runtime identifier.
• The browser-fronted (Blazor Gateway) path and the V2 live-streaming transport (testfx StreamMessageClient seam over a duplex Stream) are tracked separately under Blazor support for dotnet test #54091.

[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.

[Evangelink]

Note

This review comment was AI-assisted and manually requested after validating the findings against the current SDK and testfx code.

I found four issues in the current shape:

1. A passing exit-code-only wasm run becomes ZeroTests (exit code 8). ReportStandaloneResults(..., trxFilePath: null, ...) starts/completes an assembly but emits no TestCompleted event, so TerminalTestReporter.TotalTests stays zero. MicrosoftTestingPlatformTestCommand then replaces the successful aggregate result with ExitCode.ZeroTests. The added test only checks HasHandshakeFailure, not the final command result, so it misses this.

2. --list-tests and extension help cannot work standalone. LaunchTestHostStandalone is selected solely from the RID, including discovery/help invocations, but those modes currently deliver DiscoveredTestMessages / CommandLineOptionMessages through the pipe. Successful standalone stdout is not rendered, so discovery produces no tests and extension help disappears.

3. Standalone stdout/stderr is neither streamed nor bounded. Without a handshake, _protocolNegotiated remains false. ProcessOutputCollector.AddLine therefore never enters the branch that both writes output and calls TrimToBoundedTail; a verbose run retains all lines in memory and then discards successful output. This does not match the new “streamed stdout tail” comment.

4. The gated TRX path has a shared-file race/staleness issue. Every standalone module uses TestResults/blazor-wasm.trx, while modules run concurrently by default. They can overwrite/read one another's file, and a valid file from an earlier run can be replayed when the current host fails before writing. The filename should be unique per TestApplication (and ideally an old destination should be removed before launch).

On moving this into MTP core: detecting wasm in the existing handshake is too late to choose the transport. The SDK must decide whether to create a pipe and append --server dotnettestcli --dotnet-test-pipe ... before launching the host; MTP selects DotnetTestConnection from those arguments, constructs the named-pipe client, and only then sends the handshake over that pipe. This is a bootstrap/chicken-and-egg problem. Adding RuntimeIdentifier or transport capabilities to that handshake is still useful for validation and future negotiation, but it cannot rescue a transport that cannot connect.

I think the blocking points can be fixed cleanly if testfx exposes the decision before the handshake:

• Add an explicit launch contract such as --dotnet-test-transport pipe|stdio|websocket plus its endpoint/token, rather than having SDK infer behavior only from RID. MTP can reject unsupported combinations early (pipe on browser/WASI) and instantiate the right transport.
• Alternatively/additionally, export a build-time MSBuild property/item from the test application describing supported transports/capabilities. The SDK already reads RunProperties before launch, so it can choose without executing a probe. This also avoids hard-coding wasm forever and supports bridge hosts.
• Keep the existing versioned dotnettestcli message contract where possible. Pipe is the transport; JSON-RPC is a different protocol and does not itself solve browser IPC. For a real browser, a loopback HTTP host plus a browser-initiated authenticated WebSocket is the natural duplex transport; for WASI/headless Node, stdio plus exit code (or framed structured stdout) is simpler. HTTP POST alone works for final TRX/artifact upload but not live results, discovery, or cancellation.
• Once connected over any usable transport, extend the handshake with RuntimeIdentifier and advertised transport/control capabilities so both sides can validate the selected mode and negotiate optional behavior.

This would also let this PR use a temporary standalone fallback without making RID detection the permanent orchestration contract.