如何诊断含千余个项目的MSBuild全构建耗时以优化流程？

当然有办法！针对你这个包含1000个项目的Full Build耗时分析，我推荐几个实用的MSBuild内置工具和技巧，帮你精准定位耗时点：

这是最直接的方法，能拿到每个环节的精确耗时数据：

• 生成诊断级性能日志：运行MSBuild时加上参数 msbuild YourSolution.sln /flp:v=diag;logfile=full_build.log。生成的日志文件里会有专门的Task Performance Summary和Project Performance Summary板块，前者列出所有构建任务的总耗时、调用次数，后者统计每个项目的构建时长，你能一眼看到哪些任务或项目拖慢了整体速度。
• 轻量控制台汇总：如果不想生成超大日志文件，用 msbuild YourSolution.sln /clp:PerformanceSummary 参数，直接在控制台输出任务和项目的耗时统计，快速掌握整体耗时分布。

这个工具简直是大型解决方案构建分析的神器！把上面生成的.log文件导入进去，它会把整个构建流程转换成交互式的树形结构，每个节点都标注了精确耗时，还会自动高亮耗时最长的环节。你可以展开任意项目，查看内部每个任务的执行顺序和耗时，轻松锁定瓶颈——比如是不是某个项目的编译任务特别慢，或者某个自定义工具重复执行了太多次。

MSBuild默认会并行构建项目，但项目依赖关系可能会限制并行度：

• 尝试手动指定最大并行数，比如 msbuild YourSolution.sln /maxcpucount:8（8根据你的CPU核心数调整），对比耗时变化。如果提升不明显，要么是项目之间的依赖太紧密导致CPU无法满负荷运行，要么是某些任务本身不支持并行（比如一些老旧的自定义构建工具）。
• 结合性能日志里的Project Performance Summary，查看各个项目的开始/结束时间，能发现是不是有大量项目在等待依赖项构建，造成CPU空闲。

Full Build模式下，有些公共任务（比如资源生成、代码分析）可能在多个项目中重复执行相同操作：

• 在诊断日志里搜索重复出现的任务名称，看看是否存在可复用的环节——比如把公共资源生成逻辑抽成单独的共享项目，或者利用MSBuild的缓存机制（比如@(IntermediateOutputPath)的缓存策略）来复用已经生成的输出，减少重复劳动。

内容的提问来源于stack exchange，提问作者BlythMeister