Loading
Analyze an MSBuild solution, solution filter, or Build.proj that schedules multiple project files. USE FOR: measured idle worker nodes, `-m` that does not scale, a serial ProjectReference critical pat
The skill file stays in the publisher's repository.
Paste the copied command in a terminal. It installs this SKILL.md into that agent.
npx skills add dotnet/skills --skill build-parallelism -a cursor -y
Analyze an MSBuild solution, solution filter, or Build.proj that schedules multiple project files. USE FOR: measured idle worker nodes, `-m` that does not scale, a serial ProjectReference critical path, graph builds, or an MSBuild task that builds a Projects list. Requires at least two distinct project files whose scheduling or throughput must be analyzed. DO NOT USE for non-MSBuild build systems.
Analyze an MSBuild solution, solution filter, or Build.proj that schedules multiple project files. USE FOR: measured idle worker nodes, `-m` that does not scale, a serial ProjectReference critical path, graph builds, or an MSBuild task that builds a Projects list. Requires at least two distinct project files whose scheduling or throughput must be analyzed. DO NOT USE for non-MSBuild build systems.
-m that does not scale, a serial ProjectReference critical path, graph builds, or an MSBuild task that builds a Projects list. Requires at least two distinct project files whose scheduling or throughput must be analyzed. DO NOT USE for non-MSBuild build systems."
license: MITWork this checklist in order — it targets the usual root cause (a serial dependency chain that no number of cores can parallelize):
dotnet build /bl:{} (PowerShell: dotnet build '-bl:{}') and
inspect the node timeline to see whether more than one node ran. Every
dotnet CLI command built on the SDK's MSBuild-forwarding path (build,
msbuild, test, pack, publish, etc.) enables /maxcpucount (multiple
nodes) by default; -m:1 forces a single node. A direct MSBuild.exe
invocation is sequential by default, so pass -m explicitly to enable
parallel worker nodes there.Core → Api → Web → Tests. A long serial
chain stays serial no matter how large -m is, because each project waits on
its predecessor.ProjectReference edges that lengthen the chain — a
reference that only needs build order (not the output assembly), or one that
could be a PackageReference, forces serialization it doesn't need./graph for better scheduling./maxcpucount (or -m): number of worker nodes (processes)dotnet CLI command (build, msbuild, test, pack, publish,
etc.) passes /maxcpucount by default via the SDK's shared MSBuild-forwarding
path; -m:1 overrides it with one nodeMSBuild.exe invocation is sequential by default and requires an
explicit -m-m without a number = use all logical processorsperformancesummary and check Project Performance Summary — shows per-project time; grep for node.*assigned to check scheduling/graph)dotnet build /graph or msbuild /graph<ProjectReference> (no programmatic MSBuild task references)<ProjectReference> only after proving it is unnecessary; a slow but
valid dependency must stay in the graph<ProjectReference ... SkipGetTargetFrameworkProperties="true"> to avoid extra evaluations<ProjectReference ... ReferenceOutputAssembly="false"> for build-order-only dependenciessolution filters (.slnf) to build subsets of the solution<MSBuild Projects="@(ProjectsToBuild)" BuildInParallel="true" /> in custom targetsBuildInParallel="true", MSBuild task batches projects sequentially/maxcpucount > 1 for this to have effectIMultiThreadableTask can run on multiple threads[MSBuildMultiThreadableTask]Use the binlog MCP server (Microsoft.AITools.BinlogMcp, exposed under the binlog MCP namespace):
Step-by-step:
dotnet msbuild build.binlog -noconlog -fl "-flp:v=diag;logfile=full.log;performancesummary"full.loggrep 'Target Performance Summary' -A 30 full.log → find the bottleneck targets-m in CI (many CI runners have multiple cores)dotnet build /graph works well with structured CI pipelines