MSBuild Weekly Report — 2026-04-28 #17
Replies: 5 comments
-
🔍 Investigation: Issue #13648 — Restore fails due to missing package Microsoft.Extensions.Logging.Log4Net.AspNetCore.Upstream: dotnet/msbuild#13648 SummaryThis issue reports a NuGet restore failure (NU1101) where the package Root Cause AnalysisIssue Nature: Key Findings:
Relevant Source Code: Reproduction DetailsAttempted Reproduction:
Analysis Without Reproduction: Suggested Next Steps
Automated investigation by MSBuild Weekly Report workflow
|
Beta Was this translation helpful? Give feedback.
-
🔍 Investigation: Issue #13478 — MSBuild .up2date files can permanently hork U2D check in VSUpstream: dotnet/msbuild#13478 SummaryMSBuild's Root Cause AnalysisLocation: The Problem: (Touch Files="@(CopyUpToDateMarker)"
AlwaysCreate="true"
Condition="'@(ReferencesCopiedInThisBuild)' != '' and '$(WroteAtLeastOneFile)' == 'true'" /)This condition requires both:
Why it fails:
In these scenarios, the build succeeds but the marker file timestamp stays stale, causing VS Fast Up-to-Date check to incorrectly report the project as out-of-date on subsequent builds. Issue author's analysis (by AArnott with Copilot's assistance) confirms:
Reproduction DetailsEnvironment constraints: Unable to complete full reproduction due to sandboxed environment limitations (permission restrictions prevented creating test projects and running builds). Attempted approach: Planned to create:
Expected outcome: The marker file would remain at its initial timestamp, demonstrating the bug. Suggested Next Steps
Automated investigation by MSBuild Weekly Report workflow
|
Beta Was this translation helpful? Give feedback.
-
🔍 Investigation: Issue #13531 — TaskBuilder should force Reacquire when a task finishes while yieldedUpstream: dotnet/msbuild#13531 SummaryThis issue identifies a critical protocol violation where third-party MSBuild tasks can call Root Cause AnalysisVulnerable Code Location:
The Protocol Violation:
Evidence from Source: From TaskHost.cs (Yield method): ErrorUtilities.VerifyThrow(_yieldThreadId == -1, "Cannot call Yield() while yielding.");
_yieldThreadId = Environment.CurrentManagedThreadId;
builderCallback.Yield();From TaskHost.cs (Reacquire method): ErrorUtilities.VerifyThrow(_yieldThreadId != -1, "Cannot call Reacquire() before Yield().");
ErrorUtilities.VerifyThrow(_yieldThreadId == Environment.CurrentManagedThreadId, ...);
builderCallback.Reacquire();
_yieldThreadId = -1; // Reset only happens hereKey Observation: The Reproduction DetailsCreated a malicious task demonstrating the protocol violation: public class BadYieldTask : Task
{
public override bool Execute()
{
var buildEngine3 = BuildEngine as IBuildEngine3;
if (buildEngine3 != null)
{
buildEngine3.Yield();
// BUG: Returning without calling Reacquire()
return true;
}
return true;
}
}Expected Behavior (if fixed):
Actual Behavior (current):
Environment Limitation: Could not complete build execution due to permission restrictions in test environment, but code analysis confirms the vulnerability. Suggested Next Steps
Priority Assessment: This is a high-priority correctness issue that violates core engine invariants. While built-in tasks follow the try/finally pattern correctly, third-party task authors have no guardrails. The fix is straightforward and defensive programming best practice. Automated investigation by MSBuild Weekly Report workflow
|
Beta Was this translation helpful? Give feedback.
-
🧪 Investigation Results SummarySummary: Investigated 3 issue(s) — 0 reproduced, 0 not reproduced, 3 inconclusive
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-05-05T13:02:18.793Z.
|
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Report generated: 2026-04-28
Time window: Past 14 days (2026-04-14 to 2026-04-28)
📊 Summary Statistics
Section 1 — New Unassigned Issues
Issues created within the past 14 days that are currently open and unassigned.
\) and Unix (/) path separators, causing DirectoryNotFoundException when MSBuild tries to write cache files.Path.Combine()or platform-specific separators. Likely affects StaticWebAssets targets.[Obsolete]attribute because users with warnings-as-errors enabled would experience build breaks. Need custom attribute for soft deprecation.ManifestUtillibrary usesDirectory.GetCurrentDirectory()and other process-global APIs that are unsafe for multithreaded execution. Third-party task authors using these APIs cannot safely migrate to-mtmode.Section 2 — Older Unassigned Issues with Recent Activity
Issues created more than 14 days ago, currently open and unassigned, with comments in the past 14 days.
IBuildEngine3.Yield()but return fromExecute()without callingReacquire(), breaking the engine's one-active-builder invariant. Protocol violation by task, but engine should defend against it.TaskBuilder.ExecuteInstantiatedTaskafter task execution to forceReacquire()if task left node in yielded state. Log warning for task authors. Good candidate for contributor with engine knowledge..Up2Datemarker files are only touched when_CopyFilesMarkedCopyLocalwrites at least one changed file. Projects that rebuild without copying changed references (e.g., withPrivate=FalseorReferenceOutputAssembly=false) never update the marker, causing permanent stale detection in VS..Up2Datemarker (track successful builds vs. track copy-local changes). Priority:1 indicates high importance. Should be discussed with VS Fast-Up-To-Date team.dotnet buildto auto-discover and build all projects in a directory when no solution/project file is present, reducing need for traversal projects/solutions.Section 3 — Open Pull Requests Triage
Pull requests that are open (or draft) and were either opened within the past 14 days OR had commits/comments in the past 14 days.
🔍 Issues Flagged for Deeper Investigation
The following issues have been categorized as Bug or Regression and require deeper investigation:
.Up2Datemarker files not updated correctly for projects that don't copy changed references, causing permanent stale detection in Visual Studio. Priority:1 issue affecting VS build performance.🧪 Investigation Results
Investigation results will be added here as they complete.
Beta Was this translation helpful? Give feedback.
All reactions