MSBuild Weekly Report — 2026-04-21 #16
Replies: 6 comments
-
🔍 Investigation: Issue #13552 — Amd64 MSBuild restore does not load amd64\NuGet.Build.Tasks.dllUpstream: dotnet/msbuild#13552 SummaryMSBuild 18.3.0 (for .NET Framework) running from the Root Cause AnalysisBased on the issue evidence, this appears to be an assembly resolution path bug in the task loading infrastructure: Problem: When MSBuild.exe runs from Likely Root Cause:
Affected Components:
Impact: This could lead to:
Reproduction DetailsAttempted: Created minimal .NET project with package references to trigger NuGet restore task. What would verify the issue: # From MSBuild bin\amd64 directory
msbuild.exe /t:restore /v:diag MyProject.csproj > restore.log 2>&1
# Search for assembly load paths in log:
findstr /C:"Loading task" /C:"NuGet.Build.Tasks" restore.logSuggested Next Steps
Priority: Medium-High - While not blocking builds, loading incorrect architecture assemblies could cause intermittent failures or performance issues. Automated investigation by MSBuild Weekly Report workflow
|
Beta Was this translation helpful? Give feedback.
-
🔍 Investigation: Issue #13566 — EnableDefaultCompileItems forced to false without warning messageUpstream: dotnet/msbuild#13566 SummaryUser reports that defining custom properties/items referencing files outside the project directory (e.g., using Root Cause AnalysisBased on SDK source code analysis (Microsoft.NET.Sdk.DefaultItems.targets), the behavior stems from MSBuild's "project cone" safety mechanism: Key findings:
However, I could not locate the specific code that forcibly sets
Hypothesis: The behavior may be implemented in MSBuild task code (CheckForDuplicateItems task or SDK resolver) rather than targets files, or there's a condition I haven't found yet in the evaluation logic. Reproduction DetailsCreated minimal reproduction structure matching the issue: Attempted build but dotnet CLI unavailable in this environment - cannot confirm exact behavior. 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 SummaryThis issue describes a design flaw in MSBuild's Up-to-Date check mechanism where Root Cause AnalysisLocation: The Problem: (Touch Files="@(CopyUpToDateMarker)"
AlwaysCreate="true"
Condition="'@(ReferencesCopiedInThisBuild)' != '' and '$(WroteAtLeastOneFile)' == 'true'" /)This means the marker advances only when:
Why This Breaks:
Affected Project Types:
Reproduction DetailsAttempted Reproduction:
Expected vs. Actual:
Suggested Next Steps
Automated investigation by MSBuild Weekly Report workflow
|
Beta Was this translation helpful? Give feedback.
-
🔍 Investigation: Issue #13465 — MSBuild using last write time of symlinks instead of their targets to determine whether or not to rebuildUpstream: dotnet/msbuild#13465 SummaryMSBuild on non-Windows platforms incorrectly uses the symlink's last modification time instead of the target file's timestamp when determining if a rebuild is needed. When a symlinked source file's target is modified, MSBuild skips the rebuild because the symlink itself wasn't modified. This is inconsistent with Windows behavior, where symlink targets are properly followed. Root Cause AnalysisThe issue is confirmed in the MSBuild source code at Problem code: if (IsWindows)
{
// Windows branch properly handles symlinks
if ((data.fileAttributes & FILE_ATTRIBUTE_REPARSE_POINT) == FILE_ATTRIBUTE_REPARSE_POINT
&& !Traits.Instance.EscapeHatches.UseSymlinkTimeInsteadOfTargetTime)
{
fileModifiedTime = GetContentLastWriteFileUtcTime(path);
}
}
else
{
// Non-Windows: does NOT check for symlinks!
return File.Exists(path)
? File.GetLastWriteTimeUtc(path)
: DateTime.MinValue;
}Root cause: On non-Windows platforms (Linux, macOS), MSBuild simply calls Why it happens:
Related issues: The issue author correctly identified this and referenced #826 and #322, both related to symlink timestamp handling. Reproduction DetailsAttempted reproduction: Created test scenario based on the issue's reproduction script, but the dotnet CLI is restricted in this workflow environment, preventing actual build execution. Expected behavior from issue report:
Actual behavior from issue report:
**Issue meta(redacted)
Suggested Next Steps
Automated investigation by MSBuild Weekly Report workflow
|
Beta Was this translation helpful? Give feedback.
-
🧪 Investigation Results SummarySummary: Investigated 4 issue(s) — 0 reproduced, 0 not reproduced, 4 inconclusive
📝 NotesAll 4 investigations were inconclusive due to environment limitations (missing dotnet CLI, security restrictions on MSBuild execution). However, all investigations successfully:
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-04-28T12:14:25.203Z.
|
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Report Period: 2026-04-07 to 2026-04-21 (14 days)
Generated: 2026-04-21T12:08:15Z
📊 Quick Stats
Section 1 — New Unassigned Issues (created in past 14 days)
Section 2 — Older Unassigned Issues with Recent Activity (created >14 days ago, commented in past 14 days)
File.GetLastWriteTimeon symlink instead of target(Showing top 5 of 13 older issues with recent activity)
Section 3 — Open Pull Requests Triage (opened or active in past 14 days)
(Showing top 10 of 57 active PRs)
Note: Most PRs opened in the past 14 days are awaiting initial team review. Older PRs with recent activity are primarily in review cycles or awaiting author updates.
🔍 Issues Flagged for Deeper Investigation
The following bugs and regressions require deeper analysis:
🧪 Investigation Results
Investigation results will be added here as they complete.
Beta Was this translation helpful? Give feedback.
All reactions