我们正在使用.NET Framework 4.6,并且当前具有包含我们大多数应用程序的单片DLL.它包含大约70万行代码.每当我们进行更改时,都会花费一分钟以上的时间进行重新编译.如果可能,我们希望加快速度.

一种选择是将整体拆分为多个对等程序集,而这些程序集都不相互依赖(除了用于项目之间共享的代码的单个Common程序集之外).因此,如果更改仅限于单个程序集,则编译器只需重新​​编译此较小的DLL.此外,这些对等程序集可以并行编译,再次有可能减少编译时间.

其他人认为,.NET Core 2.x的新“增量构建”功能可以从根本上增加整体的构建时间,这意味着编译器仅可以重建已更改的整体部分,而忽略其余部分.

是真的吗,还是新的增量构建功能不起作用？

还是有人对改善编译时间的最佳方法有其他建议？

解决方法:

Incremental builds可能会帮助您使用单个整体DLL.在2.0中引入了它们,但是它主要专注于检测依赖项更改-Visual Studio已经针对您的情况进行了此操作.

但是,从What’s New in .NET Core 2.1开始：

Use of long-running SDK build servers, which are processes that span across individual dotnet build invocations. They eliminate the need to JIT-compile large blocks of code every time dotnet build is run.

我目前无法确切测试这对于大型项目建设以及小范围的隔离代码更改可能意味着什么,但是我建议尝试一下.

更新,我尝试测试这到底意味着什么,但是不幸的是没有70万行项目可以测试.我使用this MS example project并运行了2个副本-一个副本合并到一个dll中,另一个副本拆分了.我所做的每项测试,样本“整体式”组合项目的运行速度都比较快,但是我认为这些都是无效的结果,因为很难将组合式项目视为“整体式”.

我在此示例“整体”中发现了一件有趣的事情：无论是对视图进行小的更改还是对项目进行的大范围更改,我从未发现新的编译时间之间存在差异.这使我确切地质疑用JIT东西缓存这个新的构建服务器的东西.也许又是因为我的“整体”并不大.

最后,我找不到任何证据证明您真正的整体项目将在.NET Core 2.1的更改期间提供更快的构建.我可以看到证明,将其拆分为几个功能项目将带来好处.最重要的是,未更改的项目将不会重新编译.

最后,对于您而言,您将拥有一个整体的DLL,这是问题的主要部分.您和其他人在注释中建议的所有其他事项将大大增加您的构建时间,因为如果不经常更改的某些关键代码区域可以分解为其他项目,则它们不会在每次编译时都重新构建.如果它们很少更改,甚至可以将它们放入nuget包中并托管在私有nuget服务器上.这样一来,即使是在全新的开发环境中,也不会对其进行编译.

希望这可以帮助！