build-parallelism

Pass -m (or /maxcpucount) to dotnet build or msbuild. The default is 1 node, meaning builds run sequentially without the flag. Using -m with no number uses all logical processors, with each node building one project at a time.

A long serial ProjectReference chain limits parallelism regardless of core count, because each project waits on its predecessor. Capture a binlog with -bl and check whether total build time roughly equals the sum of project times on one dependency chain.

The critical path is the longest chain of dependent projects, and it determines the minimum possible build time. If project A depends on B, C, and D, and B takes 60 seconds while C and D take 5, B is the bottleneck.

Use /graph for large solutions and CI builds, where constructing the full dependency graph upfront improves scheduling and avoids redundant evaluations. Do not use it when projects dynamically discover references at build time instead of using ProjectReference.

Set ReferenceOutputAssembly="false" for build-order-only references, SkipGetTargetFrameworkProperties="true" to avoid extra evaluations, and consider converting references to PackageReference when only a pre-built NuGet output is needed. Solution filters (.slnf) also let you build subsets.

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