引入Microsoft.Net.Compilers包后编译时长大幅增加的技术咨询

我来帮你拆解下这个问题——在40个项目的小解决方案里，通过Directory.Build.props全局引入Microsoft.Net.Compilers 2.8.0后，编译时间从原来VS201x的18秒大幅增加，这个情况在使用Roslyn编译器包时挺常见的，核心原因和对应的解决办法如下：

1. 全局引入带来的编译器进程重复启动开销 #

Microsoft.Net.Compilers包的作用是把Roslyn编译器作为独立组件引入，替代VS自带的编译器实例。当你通过Directory.Build.props全局添加引用后，每个项目都会单独启动包内的csc.exe/vbc.exe进程，而不是复用VS主进程里的编译器资源。40个项目累加起来，进程启动、资源初始化的开销会被放大很多，直接拉慢总编译时间。

解决办法： #

• 放弃全局引入，只给真正需要自定义编译行为的项目单独添加这个包引用；
• 如果必须全局配置，用条件判断缩小作用范围，比如只给特定项目组添加：

  <Project>
    <ItemGroup>
      <PackageReference Include="Microsoft.Net.Compilers" Version="2.8.0" Condition="'$(YourCustomProperty)' == 'True'"/>
      <!-- 其他已存在的包 -->
    </ItemGroup>
  </Project>
  

2. 编译器版本与VS自带版本不匹配 #

你用的2.8.0是比较老的版本，和VS201x自带的Roslyn编译器版本可能存在差异。不同版本的编译器在适配VS编译环境时，会额外产生兼容性开销，比如需要加载更多适配组件，或者无法利用VS的编译缓存优化。

解决办法： #

• 优先使用Microsoft.Net.Compilers.Toolset替代旧的Microsoft.Net.Compilers包，这是微软后续推出的替代方案，对VS环境的适配更好；
• 查找VS201x对应的编译器版本，安装匹配的Microsoft.Net.Compilers包版本，减少版本差异带来的额外开销。

3. 增量编译优化失效 #

旧版本的Microsoft.Net.Compilers在增量编译的支持上不如VS自带编译器完善。全局替换编译器后，原来的编译缓存逻辑可能无法复用，导致每次编译都要重新处理更多代码，哪怕只有少量改动。

解决办法： #

• 升级到更新版本的编译器包，新版本对增量编译的优化更到位；
• 确认项目的增量编译功能已开启：右键项目→属性→生成→勾选“增量编译”选项。

4. 多项目并行编译的资源竞争 #

40个项目同时启动独立的编译器进程，会导致CPU、内存资源被争抢，尤其是机器配置不算高的情况下，进程切换和资源调度的开销会大幅拖慢编译速度。

解决办法： #

• 调整VS并行编译设置：工具→选项→项目和解决方案→生成并运行，降低“最大并行项目生成数”；
• 关闭非必要的编译诊断功能，比如取消“生成时显示诊断信息”，减少编译过程中的额外输出开销。

额外建议 #

如果你的核心需求只是使用特定的Roslyn分析规则或编译特性，没必要替换整个编译器——可以单独引入Microsoft.CodeAnalysis.FxCopAnalyzers这类分析器包，既能满足需求，又不会带来全局替换编译器的性能负担。

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