Uh oh!
There was an error while loading. Please reload this page.
Enable multithreaded MSBuild for local and PR builds - #10726
Enable multithreaded MSBuild for local and PR builds#10726Jan Provazník (JanProvaznik) wants to merge 2 commits into
Conversation
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
There was a problem hiding this comment.
Pull request overview
Enables multithreaded MSBuild for local Windows builds and public CI builds while leaving official builds unchanged.
Changes:
- Defaults local PowerShell builds to multithreaded mode.
- Enables multithreading across public Windows, Linux, and macOS CI paths.
- Identified missing equivalent default for local Unix builds.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
eng/build.ps1 | Configures the local PowerShell default. |
azure-pipelines.yml | Enables multithreading in public CI build paths. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
| if (-not $PSBoundParameters.ContainsKey("msbuildMultiThreaded")) { | ||
| $PSBoundParameters["msbuildMultiThreaded"] = -not $ci |
🔍 Build Failure AnalysisSummary — Enabling MSBuild's new Root cause: |
| Code | Task | Target | Root message |
|---|---|---|---|
MSB4018 | ResolveFileAccesses | ResolveCoreCompileFileAccesses | NullReferenceException in FileAccessManager.ReportFileAccess, thrown from Microsoft.MSBuildCache.SharedCompilation.targets:9 |
(13 occurrences across each failing leg, one per failed project, all sharing this identical stack trace.)
🤖 Generated by the Build Failure Analysis workflow using (a href="(dev.azure.com/redacted) · commit ca552a2
🤖 Automated content by GitHub Copilot. Generated by the Build Failure Analysis workflow. · auto · 92.4 AIC · ⌖ 1.74 AIC · ⊞ 13.3K · [◷]( · ◷)
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Summary
Local benchmark
Measured five clean-output restore+build runs per mode after warming the SDK, workload, and NuGet caches on an 8-core/16-logical-processor Windows machine.
Local average improved by 8.1 seconds (4.8%) and median by 5.9 seconds (3.6%). The ranges overlap, so this is directional rather than statistically conclusive.
CI benchmark
Azure Pipelines build 1566758 succeeded in every configuration. The baseline is the average build-step duration from the four most recent successful fork PR builds (1566681, 1564881, 1564777, and 1564593), which use the same cache-disabled fallback path and are therefore more comparable than trusted-branch cache builds.
The two Windows configurations improved from 703.7s to 675.8s combined (-4.0%), closely matching the 4.8% local average improvement. Linux is neutral-to-modestly faster. macOS is highly variable—the baseline samples range from 533.7s to 1,015.6s for Debug and 723.9s to 1,021.9s for Release—so the apparent Release gain should not be treated as a reliable estimate.
MSBuildCache compatibility finding
The first experiment, build 1566674, failed because the cache-disabled Windows fallback still imported
Microsoft.MSBuildCache.SharedCompilation. Its unannotatedResolveFileAccessestask was routed to a sidecar TaskHost under-mt. MSBuild then corrupted the returnedFileAccessDatastructs during TaskHost packet deserialization through interface boxing and crashed inFileAccessManager.ReportFileAccesswhen replaying a null path.The ProjectCachePlugin itself was inactive, so this was not a cache lookup or materialization race. The engine defect is tracked by dotnet/msbuild#14824.
This PR therefore keeps cache graph and cache-specific sign/pack operations process-based. Ordinary Windows fallback builds use
-mtwithout importing cache support packages; Linux and macOS ordinary builds also use-mt.Conclusion
Multithreaded MSBuild provides a modest end-to-end improvement on Windows: 4.8% locally and 4.0% in comparable PR CI, with no corrected-run failures. Linux results are consistent with a smaller improvement, while current macOS variance is too high for a precise estimate. Cache population and multithreaded execution should remain separate experiments until the TaskHost file-access serialization defect is fixed and their combined topology can be evaluated independently.