使用Solution Filters拆分MSBuild构建是否可行？及源码查询指引

1. MSBuild源码中需要查看的关键部分 #

BuildProjectReferences=false的作用是禁止自动触发项目引用的构建流程，但MSBuild仍需要读取引用项目的文件来获取输出程序集的路径、目标框架、版本等元数据，以此验证输出目录中是否存在符合要求的产物。如果要验证这一逻辑，重点查看以下源码区域：

• 项目引用解析任务：src/Tasks/ResolveProjectReferences/ResolveProjectReferences.cs，这里是处理项目引用的核心逻辑，会判断BuildProjectReferences参数是否为false，进而跳过构建，但仍会解析引用项目的基本信息。
• 构建管理器依赖处理：src/Build/BuildManager.cs，其中的依赖追踪和任务调度逻辑，会处理是否跳过引用项目的构建步骤，同时检查输出产物的有效性。
• 解决方案过滤器逻辑：src/Solution/SolutionFilter.cs，查看过滤器如何筛选项目集合，以及是否会影响项目引用的解析规则。

2. 使用Solution Filters拆分构建步骤的可行性 #

这种方式完全可行，属于解决方案过滤器的合理延伸场景：

• 解决方案过滤器的本质是对原有解决方案的项目子集进行筛选，构建时的核心逻辑与完整解决方案一致，因此拆分base项目和依赖项目分阶段构建是合理的。
• 你观察到MSBuild读取base项目文件是正常行为：即使禁用了引用项目构建，MSBuild仍需要通过读取base项目文件来确认产物的位置和属性，确保D项目能正确引用到已构建的库。如果想要完全避免读取base项目文件，建议将base项目的输出打包为NuGet包，改用包引用替代项目引用，这样CI流水线中可以直接复用预构建的包，无需加载base项目文件。
• 在CI/CD中使用这种方式时，建议为base项目的构建输出添加缓存机制，确保第二步构建时能获取到最新且有效的产物，避免因路径、版本不匹配导致构建失败。

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