mcpField
R
resolve-project-references

resolve-project-references

github.com/dotnet开发5.8k3.5k 次安装1 天前更新
代码仓库

关于 resolve-project-references

面向 MSBuild 性能诊断的开发技能，说明 ResolveProjectReferences 耗时可能反映等待依赖项目的时间，并引导分析任务自身耗时。

主要功能

  1. 01识别易误读的目标耗时
  2. 02解释等待依赖项目的时间
  3. 03查看任务性能摘要
  4. 04用 binlog MCP 排序任务自身耗时
  5. 05使用文本日志作为备用方案

适用场景

  1. 01排查报告中 ResolveProjectReferences 耗时最高的情况
  2. 02将优化方向从目标耗时转向任务自身耗时
  3. 03从构建性能摘要中定位瓶颈

MCP 相关

该技能建议使用 binlog MCP 服务的 expensive_tasks 工具，根据构建日志排列任务自身耗时。

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/dotnet/skills --skill resolve-project-references

安装后在 Claude Code 中输入/resolve-project-references确认已加载。

详细介绍

误导性的 ResolveProjectReferences 耗时

说明 ResolveProjectReferences 报告的耗时是等待时间（墙钟时间），而非 CPU 工作时间，以避免对它进行不恰当的优化。

适用场景

  • ResolveProjectReferences 在目标性能摘要中显示为耗时最长的目标
  • 开发者正试图直接优化 ResolveProjectReferences
  • 构建性能分析显示，单个目标占总构建时间的 50-80%

不适用场景

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

输入

输入必需描述
构建日志或 binlog是包含目标性能摘要的诊断构建日志或 binlog

工作流

步骤 1：确认误导性现象

确认 ResolveProjectReferences 是目标性能摘要中的耗时最长目标。这是一个具有误导性的指标。

步骤 2：说明其误导之处

报告的耗时包含等待依赖项目构建的时间，此时 MSBuild 节点已让出执行权（参见 dotnet/msbuild#3135）。在此期间，该节点可能正在其他项目上执行有用的工作。目标本身实际执行的工作很少。

步骤 3：转而查看任务自身耗时

使用任务性能摘要来识别真正的瓶颈。

首选：binlog MCP

使用 binlog MCP 服务的 expensive_tasks 工具，直接从 binlog 获取任务自身耗时排名。

备用方案：文本日志重放（MCP 不可用时）
dotnet msbuild build.binlog -noconlog -fl "-flp:v=diag;logfile=full.log;performancesummary"
grep "Task Performance Summary" -A 50 full.log

重点关注实际任务自身的耗时：

  • Csc：参见 build-perf-diagnostics 技能（第 2 节：Roslyn 分析器）
  • ResolveAssemblyReference：参见 build-perf-diagnostics 技能（第 1 节：RAR）
  • Copy：参见 build-perf-diagnostics 技能（第 4 节：文件 I/O）
  • 序列化瓶颈：参见 build-parallelism 技能

验证

  • 使用了任务性能摘要，而不是目标性能摘要
  • 未将 ResolveProjectReferences 设为优化目标
  • 已识别出一个具体任务（例如 Csc、Copy、ResolveAssemblyReference）作为真正的瓶颈

评论

支持 Markdown