MSBuild Weekly Report — 2026-03-17 #11
Replies: 10 comments
-
🔍 Investigation: Issue #13387 — Highly misleading error messages when SDK specified in global.json can't be resolvedUpstream: dotnet/msbuild#13387 SummaryWhen MSBuild encounters a project with a Root Cause AnalysisIssue Location: SDK resolution and error reporting subsystem The problem stems from the SDK resolver chain's error aggregation mechanism. When MSBuild tries to resolve
Expected behavior: The error should clearly state:
Actual behavior: Generic, ambiguous error messages that require user interpretation and debugging. Reproduction DetailsTest case from issue:
Attempted reproduction: Environment limitations prevented full local reproduction, but the issue description provides clear evidence. Workaround confirmed by author: Deleting Suggested Next Steps
Automated investigation by MSBuild Weekly Report workflow
|
Beta Was this translation helpful? Give feedback.
-
🔍 Investigation: Issue #13379 — Non-existing path in .slnf results in misleading error message when built through MSBuild taskUpstream: dotnet/msbuild#13379 SummaryWhen building a solution filter (.slnf) file that references a non-existent project through the Root Cause AnalysisThis is an error message quality regression in the MSBuild task's exception handling when invoking solution filter files. Location: The issue occurs in the MSBuild task ( The problem: When the MSBuild task invokes a .slnf file and encounters a parsing error:
The error message mentions "Line 1, position 1" which indicates the exception handler is treating the solution filter file as if it failed XML/JSON parsing, when in fact the file parsed correctly but contained invalid project references. Affected versions: .NET SDK 11.0.100-preview.3 / MSBuild 18.6.0-preview (as reported), likely affects earlier versions too. Reproduction DetailsCreated a minimal reproduction case in Expected behavior: Both invocation methods should show the same detailed error identifying the missing project path. Actual behavior: MSBuild task invocation loses error context and shows generic XML parsing error. Note: Unable to execute Suggested Next Steps
Impact: Medium severity - causes confusion during debugging as developers waste time looking for XML syntax errors that don't exist instead of fixing the actual missing project reference issue. Automated investigation by MSBuild Weekly Report workflow
|
Beta Was this translation helpful? Give feedback.
-
🔍 Investigation: Issue #13362 — Race condition in NodeManager.SendData causes crash: "Node X does not have a provider"Upstream: dotnet/msbuild#13362 SummaryA race condition exists in MSBuild's node communication layer where a Root Cause AnalysisCore Issue: Thread synchronization violation in NodeManager The race occurs due to architectural mismatch between eager cleanup and asynchronous packet processing:
Additional Vulnerabilities Identified:
Source Code ReferencesNodeManager.cs (src/Build/BackEnd/Components/Communications/NodeManager.cs):
Reproduction DetailsReproduction Status: Could not reproduce in controlled environment due to:
Theoretical Reproduction:
Suggested Next Steps
Automated investigation by MSBuild Weekly Report workflow
|
Beta Was this translation helpful? Give feedback.
-
🔍 Investigation: Issue #13366 — [Broken Build]: OOM: SWA recursive bin/ nesting + glob crash on missing exclusion directoryUpstream: dotnet/msbuild#13366 SummaryThis issue describes two interacting critical bugs in .NET SDK 10.0.103 affecting Root Cause AnalysisBug 1: Static Web Assets Recursive Nesting → OOMProblem: The SWA content discovery targets don't properly exclude Manifestation:
Key Evidence:
Likely Source: This is a .NET SDK issue, not MSBuild core. The SWA targets are in
Bug 2: FileMatcher Glob Crash on Missing Exclusion DirectoryProblem: Manifestation:
Workaround: Likely Source: Reproduction DetailsAttempted: Created a minimal
Outcome: Environment constraints prevented execution of
Confidence: High confidence this is a real, reproducible issue based on:
Suggested Next StepsImmediate (Bug 2 - Glob Crash)
Short-term (Bug 1 - SWA Recursion)
Long-term
Automated investigation by MSBuild Weekly Report workflow
|
Beta Was this translation helpful? Give feedback.
-
🔍 Investigation: Issue #13329 — AutoGenerateBindingRedirects doesn't propagate from dependencies and ReferenceCopyLocalPaths copies wrong assembly versionsUpstream: dotnet/msbuild#13329 SummaryThis is a well-documented, long-standing bug in MSBuild's .NET Framework binding redirect system. When building projects with Root Cause AnalysisAfter examining the MSBuild source code, specifically Problem 1 - Binding Redirect Propagation:
Problem 2 - Assembly Copy Conflicts:
Why This Matters:
Reproduction DetailsAttempted Scenario:
Environment Limitation: Expected Behavior (from issue):
Proposed Solution (from issue author)The issue author (etomm) has implemented a complete working solution using pure MSBuild targets with no custom tasks:
The solution uses clever MSBuild techniques including Cartesian products for version comparison and has been tested successfully on solutions with 20+ projects. Suggested Next Steps
Impact: This affects the entire .NET Framework ecosystem and has been a pain point for 8+ years. A built-in fix would eliminate runtime failures and manual maintenance for thousands of projects. Automated investigation by MSBuild Weekly Report workflow
|
Beta Was this translation helpful? Give feedback.
-
🔍 Investigation: Issue #13221 — The
|
Beta Was this translation helpful? Give feedback.
-
🔍 Investigation: Issue #12944 — error MSB4166: Child node "3" exited prematurelyUpstream: dotnet/msbuild#12944 SummaryMSBuild inter-process communication (IPC) failure occurs when building projects with .NET 10, specifically when building Entity Framework bundles. The error manifests as Root Cause AnalysisThis is an IPC (Inter-Process Communication) failure in MSBuild's multi-node build system. Based on the diagnostic logs from the issue: Key observations:
Platform-specific behavior:
Source location:
Reproduction DetailsAttempted reproduction: Reproduction steps from issue: 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
````
**Simpler repro from comments:**
Per `@sec`'s comment on 2026-03-05: Building MSBuild itself on FreeBSD with `dotnet build` triggers the issue intermittently.
**Diagnostic output structure:**
When failure occurs, MSBuild creates failure logs in `/tmp/MSBuildTemp/MSBuild_pid-*.failure.txt` containing:
````
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(...)Suggested Next Steps
Automated investigation by MSBuild Weekly Report workflow
|
Beta Was this translation helpful? Give feedback.
-
🔍 Investigation: Issue #6794 — Remove assumption that MSBuild controls AssemblyLoadContext.DefaultUpstream: dotnet/msbuild#6794 SummaryThis issue identifies hardcoded references to Root Cause AnalysisCore Problem: MSBuild's assembly loading infrastructure makes an architectural assumption that it controls
Affected Components (per issue):
Why This Matters: The community discussion reveals several high-value scenarios blocked by this limitation:
Reproduction DetailsReproduction not attempted because this is an architectural limitation, not a runtime defect with reproducible error output. The issue manifests when:
Evidence from issue: // Example locations where AssemblyLoadContext.Default is hardcoded:
// src/Shared/TaskEngineAssemblyResolver.cs:126
// src/Shared/MSBuildLoadContext.cs:82-85Suggested Next Steps
Automated investigation by MSBuild Weekly Report workflow
|
Beta Was this translation helpful? Give feedback.
-
🧪 Investigation Results SummarySummary: Investigated 8 issue(s) — 0 reproduced, 7 inconclusive, 1 not applicable
Investigation summary generated automatically. See individual comments above for full details.
|
Beta Was this translation helpful? Give feedback.
-
|
This discussion was automatically closed because it expired on 2026-03-24T11:59:21.123Z.
|
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Report Generated: 2026-03-17
Time Window: Past 14 days (2026-03-03 to 2026-03-17)
Quick Stats:
Section 1 — New Unassigned Issues (created in past 14 days)
Section 2 — Older Unassigned Issues with Recent Activity (created > 14 days ago, comment in past 14 days)
Runtime="NET"crashingSection 3 — Open Pull Requests Triage (opened or with commits/comments in past 14 days)
🔍 Issues Flagged for Deeper Investigation
The following 10 issues categorized as Bug or Regression require deeper investigation to understand root causes, identify potential fixes, and estimate effort:
Runtime="NET"crashingNote: This is the full list of 10 bugs/regressions. Investigation workflows will be dispatched for all of them.
🧪 Investigation Results
Investigation results will be added here as they complete.
Beta Was this translation helpful? Give feedback.
All reactions