build-parallelism

MSBuild defaults to /maxcpucount of 1, so builds run sequentially unless you pass -m. Even with -m, a long serial ProjectReference chain (the critical path) forces projects to wait on predecessors, so extra cores sit idle.

Build with dotnet build -m /bl to produce a binlog, then read per-project timings via the binlog MCP expensive_projects tool or replay with performancesummary. If total build time roughly equals the sum of one dependency chain's project times, that chain is the bottleneck.

The /graph flag makes MSBuild construct the full project dependency graph before building, enabling better scheduling, fewer redundant evaluations, and isolated builds. Use it for large solutions and CI builds, but avoid it when projects dynamically discover references at build time.

Set ReferenceOutputAssembly="false" on references needed only for build ordering, use SkipGetTargetFrameworkProperties="true" to skip extra evaluations, and convert references to pre-built PackageReferences where possible. Solution filters (.slnf) let you build only subsets of the solution.

Skip this approach for single-project builds, incremental build issues, or slow compilation inside one project, which need different diagnostics. It also does not apply to non-MSBuild build systems.