当 ResolveProjectReferences 成为…

在 MSBuild 性能摘要中 ResolveProjectReferences 显示为最昂贵目标时，识别其时间为等待时间而非实际工作，并转向任务自身耗时分析。

适用场景

解决思路

1. 确认 ResolveProjectReferences 出现在 Target Performance Summary 的顶部目标中，这是具有误导性的指标。
2. 解释为何该指标具有误导性：报告的时间包含等待依赖项目构建的时间，此时 MSBuild 节点被让出（参见 dotnet/msbuild#3135）；在等待期间，节点可能正在对其他项目做有用工作，而该目标本身几乎不做实际工作。
3. 转向使用 Task Performance Summary 来识别真正的瓶颈。
4. 首选：使用 binlog MCP 服务器的 expensive_tasks 工具，直接从 binlog 获取任务自身耗时排名。
5. 备选（当 MCP 不可用时）：运行 dotnet msbuild build.binlog -noconlog -fl "-flp:v=diag;logfile=full.log;performancesummary"，然后用 grep "Task Performance Summary" -A 50 full.log 查看结果。
6. 关注实际任务的自身耗时：Csc 参见 build-perf-diagnostics 技能（第 2 节：Roslyn Analyzers）。
7. ResolveAssemblyReference 参见 build-perf-diagnostics 技能（第 1 节：RAR）。
8. Copy 参见 build-perf-diagnostics 技能（第 4 节：File I/O）。
9. 序列化瓶颈参见 build-parallelism 技能。
10. 验证：确认使用了 Task Performance Summary 而非 Target Performance Summary。
11. 验证：确认未将 ResolveProjectReferences 设为优化目标。
12. 验证：确认已识别出具体任务（如 Csc、Copy、ResolveAssemblyReference）作为真正瓶颈。

适用边界 · 注意事项

• 通用构建性能优化（应改用 build-perf-diagnostics）。
• 瓶颈明显是其他目标（如 Csc、ResolveAssemblyReference）。
• 用户尚未捕获 binlog 或性能摘要。