Make Runtime=NET task host handshake architecture-agnostic

[ViktorHofer]

Summary

Runtime="NET" task host launches fail with MSB4216 whenever the worker node and TaskHost node architectures don't line up the way the original implementation expected. Tracked as #13879 (Bug A).

Terminology: the worker node is the MSBuild process that launches the task host (the "parent"); the TaskHost node is the launched Runtime="NET" task host process (the "child"). This wording was adopted following review feedback.

Two coordinated handshake changes — one on each side — close every reasonable worker/TaskHost arch combination:

1. Worker node side — CommunicationsUtilities.GetHandshakeOptions

For a NET task host the launched TaskHost node's architecture is whatever the .NET SDK shipped, not the worker node's. Emitting the worker node's arch bit produces a wire-level mismatch with already-shipped SDK TaskHost nodes whose arch differs.

Suppress the X64/Arm64 bit when invoked by the worker node for a NET task host (detected by Runtime="net" in the explicit TaskHostParameters). The TaskHost-node path (TaskHostParameters.Empty) is unaffected, so already-deployed worker nodes that still emit an arch bit continue to match.

2. TaskHost node side — NodeEndpointOutOfProcBase.IsAllowedBitnessMismatch

The .NET task host side relaxation that lets a worker node without an arch bit on the wire connect to an SDK TaskHost node. Previously only tolerated expected = X64, so any arm64 SDK TaskHost node rejected the connection. Now also tolerates expected = Arm64. True cross-arch mismatches (worker X64 ↔ TaskHost Arm64) remain rejected.

Method is promoted to internal static so the test project can exercise the tolerance matrix directly. It was a stateless pure predicate already.

Effect across worker node / SDK combinations

current = behavior with this PR applied (worker-node change in VS MSBuild, TaskHost-node change in a future SDK). For each combo, "current behavior" notes whether the SDK side needs to update.

Worker node	TaskHost node (SDK MSBuild.dll)	Wire arch bit	Old behavior	Current behavior
x86 .NET Fx VS	x64 SDK	none → x64	✅ (existing expectedIsX64 tolerance)	✅
x86 .NET Fx VS	arm64 SDK	none → arm64	❌ MSB4216 (Bug A) — the user's binlog	✅ once SDK ships with TaskHost-side expectedIsArm64 tolerance
amd64 .NET Fx VS	x64 SDK	x64 → x64	✅ (matches exactly)	✅ (after worker fix: no bit on wire; already-shipped SDK tolerates none → x64)
amd64 .NET Fx VS	arm64 SDK	x64 → arm64	❌ MSB4216	✅ once VS picks up worker-side suppression; SDK must also have TaskHost-side Arm64 tolerance
arm64 .NET Fx VS	x64 SDK	arm64 → x64	❌ MSB4216	✅ once VS picks up worker-side suppression (works against already-shipped SDKs)
arm64 .NET Fx VS	arm64 SDK	arm64 → arm64	✅ (matches exactly)	✅
old worker node (pre-this-PR)	new SDK TaskHost node	x64/arm64 → matching	unchanged	unchanged — still works if arches match, still hits Bug A if they don't (worker has no fix)

Where each fix takes effect

Failing combo	Fixed by	Ships in
x86 .NET Fx VS → win-arm64 SDK	TaskHost-side Arm64 tolerance	a new .NET SDK build that picks up this PR
amd64 .NET Fx VS → win-arm64 SDK	worker-side arch suppression + TaskHost-side Arm64 tolerance	next VS insertion of MSBuild (worker side) plus a new SDK build (TaskHost side)
arm64 .NET Fx VS → win-x64 SDK	worker-side arch suppression (existing expectedIsX64 tolerance already covers the TaskHost node)	next VS insertion of MSBuild only — no SDK update needed

The reported binlog (Roslyn build on Windows-ARM, SDK 10.0.108, x86 VS 18 MSBuild worker node) is the first row — needs the SDK side to pick this up.

Tests

src/Build.UnitTests/BackEnd/NodeEndpointOutOfProcBase_Tests.cs (6 cases):

• NoArchBitWorkerNode_X64TaskHost_IsTolerated
• NoArchBitWorkerNode_Arm64TaskHost_IsTolerated
• X64WorkerNode_X64TaskHost_NotConsideredMismatch
• X64WorkerNode_Arm64TaskHost_NotTolerated
• Arm64WorkerNode_X64TaskHost_NotTolerated
• NoArchBitWorkerNode_NoArchBitTaskHost_NotTolerated (guards against a future simplification to return receivedIsX86;)

src/Build.UnitTests/BackEnd/CommunicationsUtilities_Tests.cs (5 cases):

• GetHandshakeOptions_NetTaskHostWorkerNode_SuppressesArchBit × { x64, arm64, x86 }
• GetHandshakeOptions_NonNetTaskHostWorkerNode_KeepsX64ArchBit
• GetHandshakeOptions_NonNetTaskHostWorkerNode_KeepsArm64ArchBit
• GetHandshakeOptions_NetTaskHostNode_KeepsArchBit

All 11 pass on net10.0.

References

• Closes MSB4216 on Windows ARM: NET task host handshake never tolerates expected=Arm64; #13741 implementation diverges from description #13879 (Bug A).
• Companion logging fix: Report actual launch path in MSB4216 for Runtime="NET" task host #13889.

[Copilot]

Pull request overview

Fixes a child-side handshake check that prevented .NET Framework MSBuild parents from launching a Runtime="NET" task host on Windows-ARM. IsAllowedBitnessMismatch previously only tolerated an x64-expecting child when the parent sent no architecture bit; it now tolerates arm64-expecting children as well, while still rejecting true cross-arch mismatches (X64↔Arm64). The method is also promoted to internal static to make it directly unit-testable.

Changes:

• Extend IsAllowedBitnessMismatch to accept expectedIsArm64 in addition to expectedIsX64.
• Convert the method to internal static and refresh its doc comment.
• Add unit tests covering the no-arch-bit-parent tolerance matrix (x64/arm64 child) and rejection of true cross-arch mismatches.

Show a summary per file

File	Description
src/Shared/NodeEndpointOutOfProcBase.cs	Tolerate arm64-expecting child in bitness mismatch check; expose as internal static; update XML doc.
src/Build.UnitTests/BackEnd/NodeEndpointOutOfProcBase_Tests.cs	New #if NET tests for the tolerance matrix and cross-arch rejection.

Copilot's findings

• Files reviewed: 2/2 changed files
• Comments generated: 0

[github-actions]

Review Summary — PR #13890

Well-scoped bug fix extending the .NET task host handshake tolerance to arm64 children. The logic change is correct and the approach is sound.

Findings

#	Dimension	Severity	Summary
1	Test Coverage & Completeness	MODERATE	Missing test for "no-arch parent → no-arch child" (the path where receivedIsX86==true but method returns false)
2	Documentation Accuracy	NIT	Inherited mask comment has version/flags description inverted

Clean Dimensions (22/24)

Backwards Compatibility ✓ · ChangeWave ✓ · Performance ✓ · Error Messages ✓ · Logging ✓ · String Comparison ✓ · API Surface ✓ · Target Authoring ✓ · Design ✓ · Cross-Platform ✓ · Code Simplification ✓ · Concurrency ✓ · Naming ✓ · SDK Integration ✓ · Idiomatic C# ✓ · File I/O ✓ · Build Infrastructure ✓ · Scope & PR Discipline ✓ · Evaluation Model ✓ · Correctness ✓ · Dependency Mgmt ✓ · Security ✓

Notes

• The private → internal static visibility change is appropriate for testability; the class is already internal and the method is a pure stateless predicate.
• The behavioral change is strictly a relaxation (accepts arm64 where previously only x64 was accepted), so no ChangeWave is needed.
• The fix correctly rejects true cross-arch mismatches (e.g., parent declares X64 but child expects Arm64).

Note

🔒 Integrity filter blocked 2 items

The following items were blocked because they don't meet the GitHub integrity level.

• #13890 pull_request_read: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• #13890 pull_request_read: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".

To allow these resources, lower min-integrity in your GitHub frontmatter:

tools:
  github:
    min-integrity: approved  # merged | approved | unapproved | none

Generated by Expert Code Review (on open) for issue #13890 · ● 5.5M

[Copilot]

Copilot's findings

• Files reviewed: 4/4 changed files
• Comments generated: 0 new

[ViktorHofer]

@rainersigwald it would be great if you could also take a look :) Just want to be careful.

[ViktorHofer]

@rainersigwald please approve if the changes look good to you

[JanProvaznik]

@ViktorHofer mergeable? or do you plan to take action on last rainer's comment?