resolve-project-references

ResolveProjectReferences time is mostly wall-clock wait for dependent projects to build while the MSBuild node is yielded, not actual CPU work (see dotnet/msbuild#3135). The target itself does very little work, so the reported number is misleading.

Use the Task Performance Summary instead of the Target Performance Summary to see task self-time. The binlog MCP expensive_tasks tool ranks tasks directly from a binlog, or replay the binlog with dotnet msbuild -flp:v=diag;performancesummary and grep the Task Performance Summary section.

No. Optimizing ResolveProjectReferences directly is misguided because its time reflects waiting on dependent project builds. Instead identify the concrete task with high self-time, such as Csc, ResolveAssemblyReference, or Copy, and optimize that.

You need a diagnostic build log or binlog containing the Target Performance Summary. Capture one with a binary log build, then use the binlog MCP tools or replay it to a text log with performance summary enabled.

Use build-perf-diagnostics for general build performance optimization or when the bottleneck is clearly another target like Csc or ResolveAssemblyReference. This guidance applies only when ResolveProjectReferences misleadingly tops the Target Performance Summary.