MSBuild Weekly Report — 2026-03-31 #13
Replies: 9 comments
-
🔍 Investigation: Issue #13464 — Reënable Apphost for worker nodesUpstream: dotnet/msbuild#13464 SummaryThis is a performance optimization task tracking the re-enablement of MSBuild AppHost for worker nodes after PR #13452 reverted back to Root Cause AnalysisIncident Timeline:
Technical Implementation (PR #13452):
Then it switches Why AppHost is Slower (Hypotheses):
Source Code References:
Reproduction DetailsReproduction not attempted due to environment constraints (no bash execution access). A proper reproduction would require:
This is a performance investigation task requiring specialized profiling tools (ETW/PerfView) rather than functional reproduction. 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 targetsUpstream: dotnet/msbuild#13465 SummaryMSBuild on non-Windows platforms checks the modification time of the symlink itself rather than its target when determining whether to rebuild. This causes MSBuild to miss changes when a symlink target is modified but the symlink itself is not. The issue was fixed for Windows in PR #648 (2016) but was never implemented for cross-platform environments. Root Cause AnalysisThe root cause is in Windows branch (lines 1176-1198):
Non-Windows branch (lines 1200-1205): else
{
return File.Exists(path)
? File.GetLastWriteTimeUtc(path)
: DateTime.MinValue;
}The problem: Historical context:
Reproduction DetailsThe issue reporter provided a detailed reproduction script showing:
Environment limitation: Unable to create symlinks in current environment to verify reproduction, but the code analysis confirms the reported behavior matches the implementation. Suggested Next Steps
Recommended fix location: Automated investigation by MSBuild Weekly Report workflow
|
Beta Was this translation helpful? Give feedback.
-
🔍 Investigation: Issue #13453 — MSBuild v18 truncates configuration names with spaces when passing to Project ReferencesUpstream: dotnet/msbuild#13453 SummaryThis is a critical regression in MSBuild v18 (Visual Studio 2026) affecting C++ projects with project-to-project (P2P) references. When a configuration name contains spaces (e.g., "Debug Unicode"), the Root Cause AnalysisBased on the issue description and binlog analysis mentioned by the reporter, the problem lies in the project reference resolution pipeline, specifically in how MSBuild v18 handles property propagation to ProjectReference items. Key observations:
Affected area:
Similar historical issues: MSBuild has had similar space-handling regressions in the past, particularly around:
Reproduction DetailsCreated a minimal C++ and .NET Core reproduction setup with:
Attempted reproduction:
Expected behavior (if reproduced): Suggested Next Steps
Automated investigation by MSBuild Weekly Report workflow
|
Beta Was this translation helpful? Give feedback.
-
🔍 Investigation: Issue #13463 —
|
Beta Was this translation helpful? Give feedback.
-
🔍 Investigation: Issue #13403 — Fix importance check for target-skipped messagesUpstream: dotnet/msbuild#13403 SummaryThis is a logging regression introduced in PR #12226 where Root Cause AnalysisThe bug is in if (projectLoggingContext.LoggingService.MinimumRequiredMessageImportance > MessageImportance.Low &&
!projectLoggingContext.LoggingService.OnlyLogCriticalEvents)Problem: The
The condition checks if Fix (from closed PR #12431): The comparison should be reversed and use a helper method if (projectLoggingContext.LoggingService.MinimumRequiredMessageImportance.IsAtLeast(MessageImportance.Low) &&
!projectLoggingContext.LoggingService.OnlyLogCriticalEvents)The PR introduced a new extension method Reproduction DetailsAttempted to create a minimal project with a target having a false condition to trigger the target-skipped message logging path. However, dotnet SDK is not available in this investigation environment, preventing build execution. Expected behavior: With Actual behavior (based on issue): Target-skipped messages are never logged, breaking integration tests that assert on these messages (as reported by Suggested Next Steps
Automated investigation by MSBuild Weekly Report workflow
|
Beta Was this translation helpful? Give feedback.
-
🔍 Investigation: Issue #13416 — ArgumentNullException in InvalidProjectFileExceptionUpstream: dotnet/msbuild#13416 SummaryWhen updating NuGet packages that don't support .NET Standard 2.0 (e.g., GitVersion.MsBuild 6.*), MSBuild throws an unhandled Root Cause AnalysisThe Issue: Where it fails: // src/Build/BackEnd/Components/RequestBuilder/TaskBuilder.cs:921
throw new InvalidProjectFileException(ipex.Message, ipex);This wraps the exception, and the internal constructor attempts: // BEFORE FIX (src/Build/Errors/InvalidProjectFileException.cs)
internal InvalidProjectFileException(string message, InvalidProjectFileException innerException)
: this(innerException.ProjectFile, // ❌ Can be null!
innerException.LineNumber, ...)The Fix (PR #13179): // AFTER FIX
internal InvalidProjectFileException(string message, InvalidProjectFileException innerException)
: this(innerException.ProjectFile ?? "MSBUILD", // ✅ Null-coalescing fallback
innerException.LineNumber, ...)
````
**Triggering Scenario:**
- .NET Standard 2.0 project
- Incompatible NuGet package (requires .NET 6+)
- Visual Studio MSBuild host (not .NET CLI)
- Design-time builds or task execution
- Missing `NetCoreSdkRoot` property in VS context
---
### Reproduction Details
**Attempted Reproduction:**
Environment lacks .NET SDK CLI (`dotnet` command unavailable), preventing direct reproduction. However, based on issue description and 17 upstream comments:
**Affected Versions:**
- Visual Studio 2026 Enterprise 18.4.0-18.4.1
- MSBuild 18.4.0+6e61e96ac for .NET Framework
**Confirmed Fixed:**
- Visual Studio 18.5 Insiders (comment from `@prozolic`: _"Once I updated Visual Studio to the Insider version, I can build and debug successfully"_)
- MSBuild main branch (merged Feb 3, 2026)
**Typical Error Output:**
````
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(...)
MSBUILD : error : at Microsoft.Build.BackEnd.TaskBuilder.(ExecuteTask)d__26.MoveNext()Suggested Next Steps
Related Issues: 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 SummaryWhen a project has a global.json specifying an SDK version that isn't installed (e.g., .NET 8.0.100), MSBuild produces confusing error messages that don't clearly state what SDK version was expected or that it came from global.json. Users often resolve this by deleting global.json without understanding the root cause. Root Cause AnalysisThe issue stems from how SDK resolution error messages are aggregated and displayed in SdkResolverService.cs. When SDK resolution fails:
The problematic error message flow (lines ~280-290 in SdkResolverService.cs): loggingContext.LogError(new BuildEventFileInfo(sdkReferenceLocation),
"FailedToResolveSDK", sdk.Name, string.Join($"{Environment.NewLine} ", errors));The individual resolver error messages (from DefaultSdkResolver.cs and SDK resolver implementations) use vague phrasing like:
The core issue: Error messages treat global.json version as optional/unknown information, but MSBuild knows what's in global.json during resolution. Reproduction DetailsReproduction scenario (based on issue description):
Expected behavior: Error should clearly state:
Actual behavior (from issue):
Suggested Next Steps
Files to modify:
Automated investigation by MSBuild Weekly Report workflow
|
Beta Was this translation helpful? Give feedback.
-
🔍 Investigation: Issue #6203 — Failed to properly account for ' in stringUpstream: dotnet/msbuild#6203 SummaryMSBuild fails to properly escape single quote (apostrophe) characters when expanding item metadata within property functions. This affects users with apostrophes in their Windows usernames (e.g., "Bill O'Malley"), causing build failures when NuGet package paths or project paths contain these characters. Root Cause AnalysisThe issue stems from MSBuild's metadata expansion logic in
Reproduction DetailsCreated a minimal repro project based on team investigation (benvillalobos comment): (Project Sdk="Microsoft.NET.Sdk")
(PropertyGroup)
(TargetFramework)net8.0(/TargetFramework)
(/PropertyGroup)
(ItemGroup)
(Content Include="c:\some\path\with\user'name\file.txt")
(MetadataWithSingleQuote)c:/some'stuff(/MetadataWithSingleQuote)
(/Content)
(/ItemGroup)
(Target Name="Repro6203" BeforeTargets="Build")
(ItemGroup)
(SomeType Include="@(Content)"
Condition="$([System.String]::Copy('%(Content.MetadataWithSingleQuote)').Replace('\', '/').StartsWith('c:/'))")
(/SomeType)
(/ItemGroup)
(/Target)
(/Project)Expected Error: MSB4113 or MSB4086 due to malformed expression when metadata is expanded Workaround: Use 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-04-07T12:05:33.166Z.
|
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
MSBuild Weekly Activity Report
Report Generated: 2026-03-31
Time Window: Past 14 days (2026-03-17 through 2026-03-31)
Quick Stats
Section 1 — New Unassigned Issues
Issues created in the past 14 days that are currently open and have no assignee.
CopyTask on macOS Copy-on-Write filesystems is not resilient to concurrent copiesSection 2 — Older Unassigned Issues with Recent Activity
Issues created more than 14 days ago that received comments within the past 14 days and have no assignee.
Section 3 — Open Pull Requests Triage
Pull requests that are not closed and were either opened within the past 14 days OR had commits or comments within the past 14 days.
fixes #13453(configuration names with spaces)fixes #12776for graceful worker node shutdownfixes #13078for better I/O performance on net472Note: 9 additional automated dependency update PRs from dotnet-maestro[bot] are open but not listed above (routine maintenance).
🔍 Issues Flagged for Deeper Investigation
The following issues are categorized as bugs or regressions and require deeper investigation:
CopyTask on macOS Copy-on-Write filesystems is not resilient to concurrent copies🧪 Investigation Results
Investigation results will be added here as they complete.
Beta Was this translation helpful? Give feedback.
All reactions