MSBuild Weekly Report — 2026-03-24 #12
Replies: 7 comments
-
🔍 Investigation: Issue #13416 — [Unhandled Exception]: ArgumentNullException - Parameter "projectFile" cannot be nullUpstream: dotnet/msbuild#13416 SummaryThis issue reports an unhandled Root Cause AnalysisThe root cause was identified in the Technical details:
The fix (PR #13179): - : this(innerException.ProjectFile, innerException.LineNumber, ...)
+ : this(innerException.ProjectFile ?? "MSBUILD", innerException.LineNumber, ...)The fix adds a null-coalescing operator to use "MSBUILD" as a fallback when Trigger condition:
Reproduction DetailsAttempted reproduction: Created test scenario based on issue description (netstandard2.0 project + GitVersion.MsBuild 6.6.2), but environment limitations prevented dotnet CLI execution. Reported behavior: MSBUILD : error : This is an unhandled exception in MSBuild
MSBUILD : error : System.ArgumentNullException: Parameter "projectFile" cannot be null.
MSBUILD : error : at Microsoft.Build.Shared.ErrorUtilities.ThrowArgumentNull(String parameterName, String resourceName)
MSBUILD : error : at Microsoft.Build.Exceptions.InvalidProjectFileException..ctor(String projectFile, ...)
MSBUILD : error : at Microsoft.Build.BackEnd.TaskBuilder.d__26.MoveNext()Affected versions:
Verification by community:
Suggested Next Steps
Automated investigation by MSBuild Weekly Report workflow • Generated: 2026-03-24
|
Beta Was this translation helpful? Give feedback.
-
🔍 Investigation: Issue #13403 — Fix importance check for target-skipped messagesUpstream: dotnet/msbuild#13403 SummaryThis issue tracks a bug introduced by PR #12226 where the comparison of Root Cause AnalysisThe Bug: if (projectLoggingContext.LoggingService.MinimumRequiredMessageImportance > MessageImportance.Low &&
!projectLoggingContext.LoggingService.OnlyLogCriticalEvents)Why it's wrong:
Since The Fix (from PR #12431): public static bool IsAtLeast(this MessageImportance importance, MessageImportance requiredImportance)
{
// Smaller numeric value indicates higher importance
return importance <= requiredImportance;
}And changes the buggy line to: if (projectLoggingContext.LoggingService.MinimumRequiredMessageImportance.IsAtLeast(MessageImportance.Low) &&
!projectLoggingService.OnlyLogCriticalEvents)Why PR #12431 was closed: Reproduction DetailsAttempted reproduction:
Environment limitations: Suggested Next Steps
Impact AssessmentSeverity: Medium-High
Labels justified:
Automated investigation by MSBuild Weekly Report workflow
|
Beta Was this translation helpful? Give feedback.
-
🔍 Investigation: Issue #13387 — Highly misleading error messages when SDK specified in global.json can't be resolvedUpstream: dotnet/msbuild#13387 SummaryMSBuild SDK resolution error messages are confusing and unhelpful when a project specifies a .NET SDK version in Root Cause AnalysisIssue filed by: The issue surfaces when building the ultra repository (commit d68286cd7) on a machine without .NET SDK 8 installed. The global.json specifies SDK 8, but the error message doesn't make this clear. Current error output: Key problems identified:
Code location: Based on source code search, the SDK resolution logic is in Reproduction DetailsAttempted reproduction: Created a minimal test case with:
Result: Could not complete build test due to environment restrictions (dotnet CLI access denied in this container). However, the issue description provides clear reproduction steps and expected vs. actual behavior. Workaround noted: The issue author mentions "delete global.json, it builds just fine" - confirming that global.json with a mismatched SDK version is the root cause. 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 is a critical dual-bug issue affecting .NET SDK 10.0.103 projects using Root Cause AnalysisBug 1 — Static Web Assets Recursive NestingLocation: The Static Web Assets discovery pipeline rediscovers content that was previously copied to the output directory (
The issue reports that the Evidence from binlog: MSBuild emits Expected behavior: Workaround: Reproduction DetailsAttempted: Created a minimal Result: Environment limitations prevented running
Confidence: The issue is well-documented with concrete evidence, making reproduction highly likely if tested in a .NET 10.0.103 environment with Suggested Next Steps
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 and long-standing issue in MSBuild's .NET Framework binding redirect generation. The core problem is that Root Cause AnalysisThe issue stems from two independent but related problems in MSBuild's built-in targets: 1. Binding Redirect Propagation Gap
2. Assembly Copy Deduplication Gap
Referenced source files:
Technical ContextThe issue author (etomm) has developed a complete MSBuild-based solution using only built-in tasks (
The solution demonstrates these gaps are solvable within MSBuild's existing architecture without custom tasks or inline code. Reproduction AttemptAttempted: Creating a minimal .NET Framework class library + executable setup with transitive package dependencies (e.g., System.Runtime.CompilerServices.Unsafe with multiple versions). Limitation: .NET Framework SDK/MSBuild not accessible in the current execution environment. Cannot build .NET Framework projects to verify the runtime behavior. Expected behavior (based on issue description):
Historical ContextThis has been a pain point since at least 2016:
Multiple workarounds exist (manual Suggested Next Steps
Impact Assessment
This is a legitimate design gap in MSBuild's built-in targets that has frustrated the .NET Framework community for years. The proposed solution is technically sound and demonstrates feasibility. Automated investigation by MSBuild Weekly Report workflow
|
Beta Was this translation helpful? Give feedback.
-
🔍 Investigation: Issue #12833 — PublishProfileFullPath doesnt support relative pathsUpstream: dotnet/msbuild#12833 SummaryUser reports that Root Cause AnalysisBased on the upstream discussion and SDK source code references:
Reproduction DetailsAttempted Scenario: msbuild /restore /t:Publish /p:PublishProfileFullPath=PublishProfile.pubxmlExpected: MSBuild resolves the relative path from the current directory or project directory. Actual: The property is likely passed through as-is without path resolution, causing the publish target to fail to locate the file. Environment Limitations: Unable to execute full reproduction due to sandbox constraints, but the issue description and SDK code review confirm the behavior. Suggested Next Steps
Automated investigation by MSBuild Weekly Report workflow
|
Beta Was this translation helpful? Give feedback.
-
|
This discussion was automatically closed because it expired on 2026-03-31T12:01:14.112Z.
|
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Report Generated: 2026-03-24
Time Window: Past 14 days (2026-03-10 to 2026-03-24)
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)
Section 3 — Open Pull Requests Triage (opened or active in past 14 days)
🔍 Issues Flagged for Deeper Investigation
The following bugs and regressions from Sections 1 and 2 have been flagged for automated deeper investigation:
🧪 Investigation Results
Investigation results will be added here as they complete.
Beta Was this translation helpful? Give feedback.
All reactions