MSBuild Weekly Report — 2026-03-10

[github-actions[bot]]

Report Generated: 2026-03-10
Time Window: Past 14 days (2026-02-24 to 2026-03-10)

📊 Quick Stats

• New unassigned issues: 6
• Older issues with recent activity: 12
• Active pull requests: 43

---

Section 1 — New Unassigned Issues (created in past 14 days)

#	Author	Title	Category	Age (days)	Labels	Possible Reason	Suggested Next Steps
#13347	ViktorHofer	Introduce agentic workflows to automate mundane tasks	Feature Request	1	Area: Tasks	Team exploring GitHub agentic workflows for automation of repo maintenance tasks	Needs team discussion to define scope and automation candidates
#13334	JakeRadMSFT	Node reuse is non-functional on macOS — three bugs cause orphaned node accumulation	Bug	3	None	Three interacting bugs: (1) 50ms handshake timeout too short, (2) SessionId mismatch across terminals, (3) 60s client timeout prevents idle cleanup	Needs area label, priority assessment; detailed investigation with fixes proposed; 4 related PRs already created
#13329	etomm	AutoGenerateBindingRedirects doesn't propagate from dependencies	Bug	6	None	Binding redirects from class libraries not merged into executables; wrong assembly versions copied to output causing runtime failures	Needs triage; community has working solution in MSBuild; consider incorporating into built-in targets
#13328	jzabroski	MSBuild Property $(CurrentTopLevelTargetFramework) to capture top-level project's TargetFramework	Feature Request	6	Type: Feature	Package authors need way to detect consuming project's TFM to block incompatible runtime selections (WCF netstandard2.0 case)	Needs SDK team input; may belong in dotnet/sdk; consider impact on transitive scenarios
#13323	rainersigwald	TransactionalModePreservesAllData test is flaky	Bug	7	flaky-test	Race condition in WriteLinesToFile test - file already exists error suggests timing issue or cleanup problem	Needs investigation; may need test infrastructure improvements or retry logic
#13307	rainersigwald	Get Microsoft.NET.Build.Extensions from a package for bootstrap assembly	Bug	11	Area: Our Own Build	MSBuild repo build pulls from environment instead of package, causing .NET Framework output to fail when built with .NET SDK	Needs fix; impacts developer experience; linked to PR #13232 discussion

---

Section 2 — Older Unassigned Issues with Recent Activity (created > 14 days ago, comment in past 14 days)

#	Author	Title	Category	Created	Latest Comment Summary	Possible Reason	Suggested Next Steps
#13255	baronfel	Allow worker nodes to accept work from any active build	Feature Request	2026-02-12	Design discussion continuing	With MT-safe APIs, nodes could serve multiple builds instead of locking to one, solving thundering-herd problem	Needs design; triaged; backlog
#13252	baronfel	Binlogs should only log invariant data, not culture-specific	Feature Request	2026-02-12	Discussion on binlog reproducibility	Culture-specific formatting in binlogs breaks reproducibility and comparison	Needs design; triaged; backlog
#13241	baronfel	The BinaryLogger should capture eval timings by default	Feature Request	2026-02-11	Discussion on telemetry data	Eval performance data not captured in binlogs by default	Needs design; triaged; backlog
#13221	lewing	The Runtime="NET" crashing	Bug	2026-02-07	YuliiaKovalova investigating; may be stale version issue	TaskHost crash with Runtime="NET" parameter	Triaged; waiting on image update to see if persists
#13095	JanProvaznik	Multithreaded build for roslyn crashes in TerminalLogger	Bug	2026-01-23	Ongoing investigation	TerminalLogger crash in MT builds	Priority:2; triaged; needs investigation
#12944	Liklainy	error MSB4166: Child node "3" exited prematurely	Bug	2025-12-15	Recent activity on investigation	Worker node crash during build	Needs more info; needs investigation; Area: IPC
#12833	payn-git	PublishProfileFullPath doesn't support relative paths	Question	2025-11-25	Discussion on workarounds; Nirmal4G questioning naming expectations	Property named "FullPath" but doesn't support relative paths; baronfel suggested _PublishProfileRootFolder workaround	May need SDK input; team discussing pluggable profiles
#12832	YuliiaKovalova	Does MSBuild apply a sort to globbing?	Question	2025-11-25	Design discussion continuing	Globbing result ordering unclear; performance implications	Needs design; backlog; Area: Performance, Incremental Build
#11834	baronfel	Migrate Tasks in the MSBuild repo to the new Task type	Feature Request	2025-05-12	AR-May working on multiple tasks	Epic to modernize task implementations	Epic; triaged; Area: Tasks; in progress
#11784	rainersigwald	Confusing behavior around AfterTargets="Build" in referenced projects	Bug	2025-05-02	Design discussion	AfterTargets behavior inconsistent across project references	Triaged; Area: Engine; needs clarity
#11025	MarkKharitonov	The metaproj doesn't respect SkipNonexistentTargets property	Bug	2024-11-23	Recent activity	Generated solution metaproj ignores SkipNonexistentTargets	Priority:2; triaged
#9697	vsfeedback	No newline at the end of file in project file	Other	2024-01-30	Community discussion	Project files missing trailing newline	Help wanted; backlog; Area: API; Priority:3

---

Section 3 — Open Pull Requests Triage (opened or active in past 14 days)

#	Title	Author	Action Needed By	Status Summary	Age (days)	Reviewers
#13359	Improve logging for AppDomain assembly load tracking	OvesN	Author	Just opened draft; no description yet	<1	None
#13358	Fixed indentation for _GetCopyToOutputDirectoryItemsFromTransitiveProjectReferences	CEbbinghaus	Team	Formatting fix; needs review	<1	None
#13357	Reduce node handshake read timeout from 60s to 5s	JakeRadMSFT	Team	Part of macOS node reuse fix; needs review	<1	None
#13356	Reduce default node idle timeout from 15 min to 30s	JakeRadMSFT	Team	Part of macOS node reuse fix; needs review	<1	None
#13355	Fix node reuse probe timeout: 0ms poll → 1s wait	JakeRadMSFT	Team	Part of macOS node reuse fix; needs review	<1	None
#13354	Fix Unix SessionId in handshake for cross-terminal reuse	JakeRadMSFT	Team	Part of macOS node reuse fix; needs review	<1	None
#13353	[main] Source code updates from dotnet/dotnet	dotnet-maestro	Team	Maestro dependency update	<1	None
#13352	Build Coordinator: system-wide MSBuild node management	JakeRadMSFT	Team	Major new feature for managing nodes across builds; needs design review and testing	1	None
#13351	Fix ToolTask hang when grandchild processes inherit pipes	YuliiaKovalova	Team	Fixes long-standing issue #2981; needs review	1	None
#13350	Stage 3: Forward BuildProjectFile* callbacks from OOP TaskHost	JanProvaznik	Author	Draft; MT build work in progress	1	None
#13348	Conditionally include XSDs for .NET Framework	YuliiaKovalova	Author	Draft; just opened	1	None
#13343	[main] Update dependencies from dotnet/roslyn	dotnet-maestro	Team	Maestro dependency update	1	None
#13342	[vs18.3] Update dependencies from dotnet/arcade	dotnet-maestro	Team	Maestro dependency update	1	None
#13340	[vs17.10] Update dependencies from dotnet/arcade	dotnet-maestro	Team	Maestro dependency update	1	None
#13339	[main] Update dependencies from nuget/nuget.client	dotnet-maestro	Team	Maestro dependency update	1	None
#13337	Hash-based pipe naming for fast node discovery on Unix	JakeRadMSFT	Team	Performance optimization for node discovery	1	None
#13330	Simplify PR pool definitions	rainersigwald	Author	Draft; CI configuration work	6	None
#13321	Sample sqlite-based detail binlog-esque logger	baronfel	Author	Draft; experimental logger implementation	7	None
#13319	Enlighten RAR task	AR-May	Team	Task modernization; needs review	7	None
#13318	Fix RecursiveDir metadata loss in MT builds (TaskHost)	JanProvaznik	Team	Bug fix for MT builds; needs review	7	None
#13317	Fix thread-unsafe Dictionary in telemetry	JanProvaznik	Author	Draft; fixes #12867	7	None
#13301	Allow passing a project to build via stdin	Copilot	Author	Draft; experimental feature	12	None
#13298	Update MicrosoftBuildVersion in analyzer template	github-actions	Team	Bot-created update; needs review	12	None
#13294	Extract bootstrap/E2E test infrastructure into shared lib	Copilot	Author	Draft; test infrastructure refactoring	13	None
#13293	Localized file check-in by OneLocBuild Task	dotnet-bot	Team	Localization update; needs merge	13	None
#13290	Localized file check-in by OneLocBuild Task	dotnet-bot	Team	Localization update; needs merge	14	None
#13288	Fail early for exp and perf branches in main CI	AR-May	Team	CI improvement; needs review	14	None
#13285	Do not share assemblies of task dependencies if not on MSBuild.exe	teo-tsirpanis	Team	Task loading fix; needs review	14	None
#13278	[vs17.11] Update dependencies from dotnet/arcade	dotnet-maestro	Team	Maestro dependency update; merge conflicts	15	None
#13277	[vs17.8] Update dependencies from dotnet/arcade	dotnet-maestro	Team	Maestro dependency update; merge conflicts	15	None
#13273	Prevent tasks from modifying immutable env vars in MT	AR-May	Team	MT safety improvement; needs review	18	None
#13267	Enlighten public versions of intrinsic tasks	AR-May	Team	Task modernization; needs review	20	None
#13258	[vs18.3] Source code updates from dotnet/dotnet	dotnet-maestro	Team	Maestro dependency update	24	None
#13250	Fix flaky tests: realistic timeouts and robust assertions	JanProvaznik	Team	Test infrastructure improvements; needs review	26	None
#13227	[vs17.12] Update dependencies from dotnet/arcade	dotnet-maestro	Team	Maestro dependency update	29	None
#13226	[vs17.14] Update dependencies from dotnet/arcade	dotnet-maestro	Team	Maestro dependency update	29	None
#13215	Migrate MSBuild tests from xUnit v2 to xUnit v3	Copilot	Author	Draft; test framework migration	32	None
#13177	Migrate manifest-handling tasks to TaskEnvironment API	JanProvaznik	Team	Task modernization; needs review	36	None
#13159	[vs18.0] Update dependencies from dotnet/arcade	dotnet-maestro	Team	Maestro dependency update	36	None
#13058	Fix ASP.NET WebSite projects to copy netstandard.dll	JanProvaznik	Team	Bug fix for legacy ASP.NET projects; needs review	50	None
#12946	Fill holes in BuildEventContext construction and eval ID	baronfel	Team	Logging improvements; needs review	85	None
#12868	TaskHost IBuildEngine Callback Support spec	JanProvaznik	Team	Design spec for MT callbacks; needs review	97	None
#12557	Add support for specific inner build targets to graph	jeffkl	Team	Graph build feature; needs review	169	None

---

🔍 Issues Flagged for Deeper Investigation

#	Title	Category	Reason for Investigation
#13334	Node reuse is non-functional on macOS	Bug	Three critical bugs causing orphaned nodes on macOS; well-documented with repro steps and proposed fixes already in flight
#13329	AutoGenerateBindingRedirects doesn't propagate from dependencies	Bug	Runtime failures in .NET Framework projects; community has working solution that should be evaluated for inclusion
#13323	TransactionalModePreservesAllData test is flaky	Bug	Test infrastructure issue causing CI failures; needs root cause analysis
#13307	Get Microsoft.NET.Build.Extensions from package	Bug	Blocks proper builds of MSBuild repo with .NET SDK; impacts developer experience
#12944	error MSB4166: Child node exited prematurely	Bug	Worker node crash after dotnet 9→10 upgrade; needs investigation with diagnostic logs

---

🧪 Investigation Results

Investigation results will be added here as they complete.

AI generated by MSBuild Weekly Activity Report

• expires on Mar 17, 2026, 12:51 PM UTC

[github-actions[bot]]

🔍 Investigation: Issue #13334 — Node reuse is non-functional on macOS — three bugs cause orphaned node accumulation

Upstream: dotnet/msbuild#13334
Classification: Bug / Regression (confidence: 0.95)
Reproduction: ⚠️ Unable to reproduce (macOS-specific issue, Linux environment available)

Summary

This is a critical macOS-specific bug affecting MSBuild's out-of-process node reuse mechanism. Three independent bugs combine to make node reuse completely non-functional on macOS, causing indefinite accumulation of orphaned MSBuild worker processes. The issue was reported by a Microsoft team member (JakeRadMSFT) with detailed code analysis and source file references that have been verified against the current codebase.

Root Cause Analysis

I verified the referenced code locations in the MSBuild repository. The issue involves three interacting bugs:

Bug 1: 50ms Handshake Timeout (Primary)

• Location: CommunicationsUtilities.cs:883 — Verified: timeout = Math.Max(timeout, 50);
• Impact: When the scheduler attempts to reuse an idle node with timeout=0 ("poll mode"), Unix platforms clamp this to 50ms minimum
• Root cause: 50ms is insufficient for a sleeping node process to wake up, read the handshake from the named pipe, validate it, and respond
• Result: All reuse attempts timeout and fail, forcing the scheduler to spawn new nodes instead

Bug 2: SessionId Mismatch on Unix

• Location: CommunicationsUtilities.cs:293 — Verified: sessionId = currentProcess.SessionId;
• Impact: On Unix/macOS, Process.SessionId calls getsid() which returns the session leader PID
• Root cause: Each terminal window has a different session leader PID. Nodes spawned from Terminal 1 can never be reused by builds in Terminal 2 or VS Code — the handshake validation fails on SessionId mismatch
• Result: Cross-terminal reuse is impossible, even if Bug 1 were fixed

Bug 3: 60-Second ClientConnectTimeout

• Location: NodeEndpointOutOfProcBase.cs:48 — ClientConnectTimeout = 60000
• Impact: When a reuse probe connects, writes handshake, then times out after 50ms, the node-side remains blocked reading the incomplete handshake for up to 60 seconds per field
• Root cause: Multiple concurrent builds continuously probe idle nodes. Each failed probe blocks the node for 60s, preventing the idle timeout (MSBUILDNODECONNECTIONTIMEOUT) from ever triggering
• Result: Nodes never exit despite being idle; they accumulate indefinitely

Interaction Pattern:

Build 1 → Finds 0 idle nodes → Spawns 8 new nodes → Completes
Build 2 → Finds 8 idle nodes → All reuse attempts fail (Bug 1 + Bug 2)
        → Spawns 8 NEW nodes (now 16 total)
        → Failed probes keep first 8 nodes stuck (Bug 3)
Build 3 → Finds 16 idle nodes → All fail → Spawns 8 more (now 24 total)
        → Failed probes keep all 16 alive...
...hundreds of nodes accumulate...

Reproduction Details

Attempted: Local reproduction in Linux CI environment
Result: Cannot reproduce — issue is macOS-specific (requires getsid() behavior and macOS terminal session management)

Expected reproduction on macOS:

1. Clone a .NET solution with 20+ projects
2. Open 3+ terminal windows
3. Run dotnet build in each terminal concurrently
4. After builds complete: pgrep -f 'MSBuild.dll.*nodemode' | wc -l
5. Expected: Dozens of orphaned nodes still running, accumulating across builds
6. Wait 15+ minutes — nodes remain alive (Bug 3 prevents timeout)

Verification of code locations:

• ✅ Confirmed Math.Max(timeout, 50) at CommunicationsUtilities.cs:883
• ✅ Confirmed sessionId = currentProcess.SessionId at CommunicationsUtilities.cs:293
• ✅ Both code patterns match the issue description exactly

Suggested Next Steps

1. Verify on macOS: Reproduce using the steps above in a macOS environment with .NET SDK 9.0+
2. Implement proposed fixes:
   • Fix 1: Add dedicated reuse timeout constant (~1000ms) instead of polling with 0ms
   • Fix 2: Set sessionId = 0 on non-Windows platforms (Unix doesn't need RDP session isolation)
   • Fix 3: Reduce ClientConnectTimeout to match reuse timeout, or add broken pipe detection
3. Add telemetry: Track successful vs. failed node reuse attempts per platform
4. Consider regression test: Add CI test on macOS that verifies node reuse works across multiple builds
5. Priority: High — affects all macOS developers using .NET SDK, causes significant memory waste and performance degradation

Impact severity: This completely breaks a core MSBuild performance optimization on macOS. The proposed fixes are surgical (3 small code changes) and well-justified.

---

Automated investigation by MSBuild Weekly Report workflow

Generated by MSBuild Issue Investigation — Worker Agent

[github-actions[bot]]

🔍 Investigation: Issue #13329 — AutoGenerateBindingRedirects doesn't propagate from dependencies and ReferenceCopyLocalPaths copies wrong assembly versions

Upstream: dotnet/msbuild#13329
Classification: Bug (confidence: 0.95)
Reproduction: ⚠️ Inconclusive (environment limitations prevented build execution)

Summary

This is a well-documented longstanding bug in MSBuild's .NET Framework binding redirect generation and assembly copy logic. When building .NET Framework executables with AutoGenerateBindingRedirects=true, MSBuild fails to propagate binding redirects from referenced class libraries and copies multiple conflicting assembly versions to output, resulting in "Could not load file or assembly" runtime failures.

Root Cause Analysis

The issue stems from two architectural problems in MSBuild's .NET Framework build targets:

Problem 1: Binding Redirect Propagation Failure

• The GenerateBindingRedirects target only analyzes the current project's direct and transitive package references
• It does not read or merge binding redirects from .config files of referenced class library projects (@(ReferencePath))
• When ClassLibrary.csproj generates binding redirects (e.g., System.Runtime.CompilerServices.Unsafe → 6.0.3.0), and ExecutableApp.csproj references it, the executable's binding redirect generation ignores the class library's already-resolved redirects
• This violates the expected composition model where dependencies' resolved assembly versions should flow upward

Problem 2: ReferenceCopyLocalPaths Duplication

• The ResolveAssemblyReferences target populates @(ReferenceCopyLocalPaths) based on assembly references from both direct references and transitive dependencies
• When multiple versions of the same assembly exist in the dependency graph (e.g., 6.0.0.0, 6.0.1.0, 6.0.3.0), all versions are added to @(ReferenceCopyLocalPaths)
• The copy operation is non-deterministic or uses alphabetical/path-based ordering rather than version-aware deduplication
• Result: The wrong version often overwrites the correct version, causing the runtime to load an assembly version that doesn't match the binding redirect

Core Design Flaw:
These targets operate independently without coordination:

• Binding redirects are generated without considering which assembly versions will actually be copied
• Assembly copies proceed without checking which versions the binding redirects expect
• No validation occurs between the two processes

Reported Solution

The issue author has developed a comprehensive pure-MSBuild workaround using two custom targets:

1. MergeBindingRedirectsFromDependencies — Uses XmlPeek to read .config files from @(ReferencePath), extracts binding redirects, computes maximum versions via Cartesian product technique, and merges into @(SuggestedBindingRedirects) before MSBuild's built-in generation

2. FixReferenceCopyLocalPaths — Uses GetAssemblyIdentity to read actual DLL versions, deduplicates @(ReferenceCopyLocalPaths) by assembly identity, removes versions that don't match binding redirects, keeping only the correct version

This workaround demonstrates the problems are solvable within MSBuild's existing task infrastructure.

Related Historical Context

This issue connects to multiple longstanding bugs:

• #1310 (2016): (AutoGenerateBindingRedirects) doesn't work for class libraries
• MSBuild missing automatic binding redirects when using NuGet transitive pinning  dotnet/sdk#40284 (2023): MSBuild missing automatic binding redirects with transitive dependencies
• #10821 (2024): Binding redirects not generated for transitive packages with CPM (closed)

The fact that these issues span 8+ years indicates a fundamental architectural limitation in how MSBuild handles .NET Framework binding redirects.

Reproduction Details

Attempted: Creation of minimal reproduction with:

• ClassLibrary.csproj referencing System.Runtime.CompilerServices.Unsafe 6.0.0 package
• ExecutableApp.csproj referencing the class library
• Both configured with (TargetFramework)net48(/TargetFramework) and (AutoGenerateBindingRedirects)true(/AutoGenerateBindingRedirects)

Status: Environment constraints prevented dotnet CLI execution and build testing. However, the issue description provides:

• Detailed reproduction steps with specific project structure
• Clear "Current Behavior" vs "Expected Behavior" comparison
• Working MSBuild solution demonstrating both problems exist and are fixable
• Testing results confirming successful resolution across 20+ project solutions

The high quality of the issue report (architectural analysis, working solution with code, testing evidence) strongly validates the problem's existence.

Suggested Next Steps

1. MSBuild Team Review — Request the MSBuild team (@dotnet/msbuild-triage) to evaluate incorporating the proposed solution into built-in targets:

   • Enhance GenerateBindingRedirects to read dependency .config files and merge redirects
   • Fix ResolveAssemblyReferences to deduplicate assemblies by identity with version-aware selection
   • Add diagnostic warnings (MSB3XXX) for assembly version conflicts

2. Impact Assessment — Analyze breaking change potential:

   • Current behavior is incorrect but may be "relied upon" by workarounds
   • Proposed fixes should be opt-in initially ((FixBindingRedirectPropagation)true(/FixBindingRedirectPropagation))
   • Consider default-on for .NET 9+ SDK with .NET Framework projects

3. Community Workaround — Until fixed in MSBuild:

   • Document the author's solution in official docs
   • Consider publishing as a community NuGet package (MSBuild.BindingRedirectFix.targets)
   • Add to dotnet/sdk or dotnet/msbuild samples

4. Testing — If productized, ensure compatibility with:

   • Central Package Management (CPM)
   • Mixed .NET Framework / .NET Standard references
   • Multi-targeting projects
   • Incremental build scenarios

5. Deprecation Path — Since .NET Framework is in maintenance mode, evaluate:

   • Priority vs. .NET 8+ improvements
   • Support lifetime alignment with .NET Framework LTS

---

Automated investigation by MSBuild Weekly Report workflow

Generated by MSBuild Issue Investigation — Worker Agent

[github-actions[bot]]

🔍 Investigation: Issue #13323 — TransactionalModePreservesAllData test is flaky

Upstream: dotnet/msbuild#13323
Classification: Bug - Flaky Test (confidence: 0.95)
Reproduction: ⚠️ Inconclusive (test infrastructure issue - race condition in transactional mode)

Summary

The TransactionalModePreservesAllData test in WriteLinesToFile_Tests.cs is failing sporadically with error MSB3491: "Cannot create a file when that file already exists." This indicates a race condition in MSBuild's transactional file write implementation when multiple parallel builds attempt to write to the same output file simultaneously.

Root Cause Analysis

The test exercises MSBuild's transactional mode for WriteLinesToFile task, which uses atomic file replacement to prevent corruption during concurrent writes. The failure occurs at line 505 in WriteLinesToFile_Tests.cs where the test asserts buildResult.ShouldBeTrue() after running 4 parallel projects that all write to the same output.txt file using Overwrite="true".

Error details:

error MSB3491: Could not write lines to file "...\output.txt". Cannot create a file when that file already exists.

This "file already exists" error during file creation suggests a race condition in the atomic replacement logic:

1. Transactional mode creates a temporary file
2. Writes content to the temporary file
3. Attempts to atomically replace the target file with the temp file (likely using File.Replace or File.Move)
4. Race condition: Between checking if target exists and performing the atomic operation, another parallel build may have already created/replaced the file

The test uses Overwrite="true" with 4 parallel projects all targeting the same output file. While transactional mode is designed to handle this, the implementation appears to have a timing window where:

• Process A prepares temp file, checks target
• Process B prepares temp file, completes atomic replace
• Process A attempts atomic replace but fails because the file state changed

Key source location: src/Tasks.UnitTests/WriteLinesToFile_Tests.cs line 460-505

Reproduction Details

The test creates 4 child projects that build in parallel using BuildInParallel="true", each attempting to overwrite the same output.txt file. The race condition is intermittent because it depends on precise timing of the parallel builds.

Test structure:

• Parent project: ParallelBuildProject.csproj with MSBuild task calling 4 child projects in parallel
• Each child project: Writes a single line to shared output.txt with Overwrite="true"
• Expected: Build succeeds with transactional atomic file replacement
• Actual (flaky): Build fails with MSB3491 when timing window is hit

The test comment notes: "With transactional mode and Overwrite=true, build should succeed. Atomic replace prevents file corruption even with concurrent writes." However, the atomic replacement implementation has a race condition that causes intermittent failures.

Suggested Next Steps

1. Review WriteLinesToFile transactional implementation - Check the atomic file replacement logic for race conditions in concurrent scenarios. The implementation may need to:

   • Use a unique temp file name per process to avoid conflicts
   • Implement retry logic with exponential backoff for the atomic replace operation
   • Add better synchronization/locking around the temp-to-final file transition

2. Add test retry/tolerance - Given the race condition is in production code (not test infrastructure), consider:

   • Marking the test with [Retry] attribute or similar to reduce CI noise
   • Adding a timeout/retry mechanism within the test itself
   • Documenting the known race condition until the underlying issue is fixed

3. Search for similar issues - Check if other parallel write scenarios in MSBuild have similar race conditions with transactional mode

4. Consider mutex/lock - The transactional mode may need a cross-process mutex or file lock to truly guarantee atomic replacement in highly parallel scenarios

---

Automated investigation by MSBuild Weekly Report workflow

Generated by MSBuild Issue Investigation — Worker Agent

[github-actions[bot]]

🔍 Investigation: Issue #13307 — Get Microsoft.NET.Build.Extensions from a package for bootstrap assembly

Upstream: dotnet/msbuild#13307
Classification: Bug (confidence: 0.95)
Reproduction: ⚠️ Inconclusive (infrastructure limitation)

Summary

The MSBuild bootstrap build process incorrectly copies Microsoft.NET.Build.Extensions.dll based on the build environment's MSBuildExtensionsPath value. When building with the .NET SDK, the net10.0 version is copied instead of the net472 version needed for .NET Framework 3.5 task support, breaking .NET Framework builds.

Root Cause Analysis

The issue is in eng/BootStrapMsBuild.targets lines 100-101:

(InstalledMicrosoftExtensions Include="$(MSBuildExtensionsPath)\Microsoft\**\*.*"
                              Exclude="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\NodeJs\**" /)

The problem manifests as follows:

1. When building with -msbuildEngine dotnet: MSBuildExtensionsPath points to the .NET SDK installation, causing the bootstrap process to copy the net10.0 version of Microsoft.NET.Build.Extensions.dll

2. When building with Full Framework MSBuild: MSBuildExtensionsPath points to Visual Studio's MSBuild, causing the net472 version to be copied

3. The consequence: The bootstrap layout is inconsistent based on build environment, and .NET 3.5 targets fail to find the expected net472 assembly when the repo is built with the .NET SDK

This issue was discovered during PR #13232 (Isolate MSBuildTaskHost from rest of MSBuild Codebase), where test failures revealed the bootstrap layout inconsistency. The PR author implemented a workaround but flagged it as "super hacky" and noted the underlying bootstrap issue needs proper resolution.

Key source files:

• eng/BootStrapMsBuild.targets (lines 100-101) - where environment-dependent copy occurs
• Related to MSBuildTaskHost.exe and .NET Framework 3.5 task execution support

Reproduction Details

Attempted reproduction: Created a minimal .NET 3.5 console project to exercise the Microsoft.NET.Build.Extensions dependency, but encountered infrastructure limitations preventing execution.

Expected behavior: The bootstrap build should produce a consistent layout regardless of whether the repo is built with dotnet build or Full Framework MSBuild.

Root issue: The bootstrap process relies on the ambient MSBuildExtensionsPath instead of explicitly sourcing Microsoft.NET.Build.Extensions from a stable, versioned package reference.

Suggested Next Steps

1. Package-based approach (recommended): Modify bootstrap targets to reference Microsoft.NET.Build.Extensions as a NuGet package dependency rather than copying from MSBuildExtensionsPath. This would ensure the correct target framework-specific version is always available.

2. Explicit TFM selection: Add logic to BootStrapMsBuild.targets to explicitly select and copy the net472 version of Microsoft.NET.Build.Extensions.dll when building the .NET Framework bootstrap output, regardless of build environment.

3. Validate bootstrap layout: Add build-time or test-time validation to ensure bootstrap outputs contain all required assemblies for their target framework, catching this class of issue earlier.

4. Documentation: Document the bootstrap build expectations and MSBuildExtensionsPath dependency in eng/README.md or similar, to help future contributors understand the constraints.

---

Automated investigation by MSBuild Weekly Report workflow

Generated by MSBuild Issue Investigation — Worker Agent

[github-actions[bot]]

🔍 Investigation: Issue #12944 — error MSB4166: Child node "3" exited prematurely

Upstream: dotnet/msbuild#12944
Classification: Regression (confidence: 0.85)
Reproduction: ⚠️ Inconclusive (environment-specific, cannot reproduce in standard Linux environment)

Summary

This is a regression introduced in .NET 10 where MSBuild's inter-process communication (IPC) between parent and child build nodes fails with a "Broken pipe" error during parallel builds. The issue primarily affects Entity Framework bundle builds in Docker containers and FreeBSD systems, and appears to be intermittent, requiring multiple build attempts to trigger.

Root Cause Analysis

The error MSB4166: Child node "3" exited prematurely originates from MSBuild's multi-node build orchestration system. Based on the diagnostic logs provided in the issue:

Stack trace from failure log:

System.IO.IOException: Broken pipe
 ---> System.Net.Sockets.SocketException (32): Broken pipe
   at System.IO.Pipes.PipeStream.WriteCore(ReadOnlySpan`1 buffer)
   at Microsoft.Build.BackEnd.NodeEndpointOutOfProcBase.RunReadLoop(...)

Key findings:

1. Location: src/Build/BackEnd/Components/Communications/NodeEndpointOutOfProc.cs - handles communication between MSBuild parent process and out-of-process worker nodes
2. Error source: The MSB4166 error message is defined in src/Build/Resources/Strings.resx and is triggered when a child node terminates unexpectedly during build
3. Labels: Issue tagged with "Area: IPC", "needs-more-info", "needs-investigation" by the MSBuild team
4. Platform specificity: Successfully reproduces on FreeBSD 15, fails to reproduce on standard Linux systems (confirmed by MSBuild team member @GangWang01)

Likely causes:

• Named pipe/Unix domain socket reliability issues on certain platforms (Docker, FreeBSD)
• Race condition in IPC cleanup during node shutdown
• Possible .NET 10 runtime changes to pipe handling that are less robust on non-standard platforms
• Timing-dependent issue that only manifests under specific system load or resource constraints

Reproduction Details

Attempted reproduction: Created minimal EF Core + Docker setup based on issue description, but cannot reproduce in GitHub Actions Linux environment.

Confirmed reproduction (from issue comments):

• Environment: FreeBSD 15 with .NET 10 SDK
• Method: Build MSBuild itself or VMR with parallel builds
• Trigger: Run dotnet build multiple times - error is intermittent
• Success rate: Not deterministic, requires multiple attempts

Original report steps:

RUN dotnet tool install dotnet-ef --version 10.* --create-manifest-if-needed
RUN dotnet ef migrations bundle --self-contained -r linux-x64 -p ./Db/Db.csproj -s ./Api/Api.csproj -o efbundle --verbose

Why reproduction failed:

1. Cannot reproduce in standard CI environment (GitHub Actions Ubuntu)
2. Requires specific platform conditions (FreeBSD, certain Docker configurations)
3. Issue is intermittent/race condition - may require many attempts
4. Lack of .NET 10 SDK in test environment (current runner has earlier version)

Suggested Next Steps

1. MSBuild team follow-up: Issue assigned to @GangWang01 for investigation - waiting for minimal repro project from reporter
2. Platform-specific testing: Test on FreeBSD 15 and various Docker configurations with .NET 10
3. IPC diagnostics: Add more detailed logging to NodeEndpointOutOfProcBase.RunReadLoop to capture pipe state before failure
4. Workaround investigation: Test if limiting parallel builds (/maxcpucount:1) prevents the issue
5. Compare .NET 9 vs 10: Diff IPC/pipe handling code between .NET 9 and 10 to identify regression point
6. Related issue review: Check Broken Pipe error when using dotnet 10/msbuild under FreeBSD 15 dotnet/dotnet#4226 mentioned in comments as potentially related

Monitoring: Issue remains open with "needs-investigation" label. MSBuild team is actively engaged.

---

Automated investigation by MSBuild Weekly Report workflow

Generated by MSBuild Issue Investigation — Worker Agent

[github-actions[bot]]

🧪 Investigation Results Summary

Summary: Investigated 5 issue(s) — 0 reproduced, 3 not reproduced, 2 inconclusive

#	Title	Classification	Reproduced?	Summary	Details
#13334	Node reuse is non-functional on macOS — three bugs cause orphaned node accumulation	Bug/Regression	⚠️ Unable (macOS-specific)	Critical macOS-specific bug with three interacting issues: 50ms handshake timeout too short, SessionId mismatch preventing cross-terminal reuse, and 60s ClientConnectTimeout causing indefinite node accumulation.	View details
#13329	AutoGenerateBindingRedirects doesn't propagate from dependencies and ReferenceCopyLocalPaths copies wrong assembly versions	Bug	⚠️ Inconclusive	Well-documented longstanding bug where binding redirects fail to propagate from referenced class libraries, and assembly copy logic duplicates conflicting versions causing runtime failures. Issue author provides comprehensive MSBuild workaround.	View details
#13323	TransactionalModePreservesAllData test is flaky	Bug (Flaky Test)	⚠️ Inconclusive	Race condition in WriteLinesToFile transactional mode when multiple parallel builds write to the same file. Test fails with MSB3491 "file already exists" error due to timing window in atomic replacement logic.	View details
#13307	Get Microsoft.NET.Build.Extensions from a package for bootstrap assembly	Bug	⚠️ Inconclusive	Bootstrap build incorrectly copies Microsoft.NET.Build.Extensions.dll based on MSBuildExtensionsPath, resulting in wrong TFM version (net10.0 vs net472) breaking .NET Framework 3.5 task support.	View details
#12944	error MSB4166: Child node "3" exited prematurely	Regression	⚠️ Inconclusive	.NET 10 regression where IPC between parent/child build nodes fails with "Broken pipe" error. Platform-specific issue affecting Docker containers and FreeBSD systems. Intermittent, requires multiple build attempts.	View details

---

Investigation summary generated automatically. See individual comments above for full details.

Generated by MSBuild Investigation Summary

[github-actions[bot]]

This discussion was automatically closed because it expired on 2026-03-17T12:51:11.964Z.

Closed by Workflow