如何减少MSBuild次数

Question

我的情况

在C＃项目中我正在研究我们有一个相当大的解决方案（80多个项目）。现在，使用Visual Studio 2008中的MSBuild，重建时间为5分钟+确实变得非常严重。

在我上周做的分析中，我发现我的构建时间花费如下：

1. 将文件复制到项目并将其重新复制到依赖于它的项目（CopyToLocal）等（60％）

2. 调用postbuild进行反编译/编译。 （20％）

3. 进行实际编辑等（20％）

除了'普通'项目bin\debug文件夹输出也被复制到外部目录以设置主'加载程序'。主程序结构有点像这样：

\loader\bin\loader.exe

\loader\plugin\plugin1\plugin1.dll

\loader\plugin\plugin1\somedependency.dll

我做了什么

为了让事情变得更快，我想到了以下几点：

1. 将所有文件复制到一个大bin目录中，不要使用 CopyTolocal 。我不喜欢这个，因为我们不能再使用相同DLL文件的不同版本，而且我的bin目录变得非常混乱。

2. Use parallelism (/m) for MSBuild。这对构建时间的帮助很小。

3. 尝试减少项目之间的依赖关系，这当然是一件好事。

4. 投资硬件。我发现了一些research on solid-state drives，但这看起来并不乐观。

我的问题

我还注意到，当我对依赖树的根目录下的项目进行更改时，所有内容都会重建。即使改变仅在“私人”部分，并且项目的界面没有改变。

MSBuild是否使用依赖项目的时间戳来确定项目是否需要重建？

这可以改为不同的条件吗？例如，文件的校验和？

除了这个特定的建议，我肯定会感谢所有建议，以加快构建时间。

Answer 1

我正在开发500多个C＃应用程序项目。项目并行编译，copylocal设置为false。编译时间约为37分钟，没有单元测试和代码覆盖率。增量构建需要13分钟而代码没有任何变化。

如果我关闭并行编译并将copylocal设置为true，则编译时间不超过1小时40分钟。

我有本地构建，门控签入构建和使用部署阶段（夜间构建）的服务器构建的不同配置。

以下是我的经历：

1. 如果要在不将CopyLocal设置为false的情况下并行构建项目，则将输出文件复制到一个目录并不是一个好主意。当多个项目引用相同的程序集时，我的程序集有时会被锁定，而MSBuild试图同时将此引用复制到输出文件夹。 This solution对我非常有帮助。我为所有引用设置了copylocal为false，并且我的构建目录大小降低了10倍（I / O减少了10倍）。我有一个不同的本地构建和服务器构建设置。门控签入构建和完全部署构建的不同设置。
2. 如果启用并行构建，构建会更快，更快。如果您拥有强大的构建服务器，那么/m:2版本应该比/m:1版本快2倍。它与项目之间的依赖关系无关（如果copylocal设置为false）。
3. 如果要进行快速增量构建，则应减少项目之间的依赖关系。它对完整版本没有影响（copylocal false）。增量编译时间取决于构建树中已更改的项目位置。

是的，MSBuild使用依赖项目的时间戳来确定项目是否需要重建。它将输入文件（代码文件，引用的程序集，临时文件，...）时间戳与输出程序集进行比较。如果更改了某些内容，则会重新编译您的项目。尝试减少项目之间的依赖关系数量，以尽量减少重新编译。如果您的更改仅在项目的“私有”部分中，则将更改输出程序集，更改程序集时间戳，并且还将重建所有相关项目。你无能为力。

使用诊断详细程度运行您的构建两次而不更改代码，并像我描述的here一样“完全”检查“构建目标”CoreCompile。您的项目文件可能有问题，每次都会重新编译项目。如果您不更改任何内容，则构建日志不应包含“构建目标”CoreCompile“完全”日志。

我们的构建服务器是虚拟机，而不是真正的硬件。将虚拟机用于构建服务器并不是一个好主意，但这不是我的决定。

如果您有多GB RAM，请尝试将其中的一部分用作内存中的硬盘驱动器。你的构建应该快得多：）

SSD驱动器每天对高I / O敏感。它会对保修产生影响。

我希望它可以帮助某人......;）

Answer 2

我们也有很大的解决方案。构建和编译都是关于I / O.

固态硬盘非常有前途。一位同事在他的笔记本电脑中安装了一个固态驱动器，发现它现在比他庞大的主开发盒快得多。没有细节，但他声称要快很多倍。

我们一直在摆弄解决方案文件夹来对项目的各个部分进行分组：这使得开发人员更容易卸载他们没有工作的项目。

/m很少有助于.NET调试版本。几周前我对此进行了一系列测试，发现了一些细微差别。发现：

• 由于我的构建受I / O约束，因此使用 / m：2-4 会使调试构建更慢。
• 通常更快地发布版本。
• 代码分析会增加很多时间。

大图：实际上，与获取源代码和运行单元测试相比，编译对我来说是一个相当小的成本。在我们的构建服务器上，集成测试和打包几乎一直都是。对于我的开发框，我安排了一个批处理文件，它可以在我上班前和我在午餐时获取源代码，构建，运行单元测试。够好了。

在构建服务器上，它更复杂。我们正在考虑在各种机器上设置链式并行CruiseControl.NET构建。我们正在使用VSTS构建，但像这样水平扩展太昂贵（而且耗时）。

我的细节导向的人数。配置从最慢到最快，运行msbuild“bigsolution.sln”/ target：clean - 在每个之间。

1. / m：4，使用代码分析调试1:38
2. / m：1，使用代码分析进行调试1:30
3. / m：4，调试无代码分析1:30
4. / m：1，调试无代码分析1:30
5. / m：1，发布代码分析：1：30
6. / m：4，发布代码分析：1：05
7. / m：4，无代码分析发布：0：53

无需重建或清理即可构建时间：~4-10秒

Answer 3

MSBuild构建时间是一个多维问题。好消息很容易解决：

与构建机器上运行的大多数进程不同，构建进程因CPU，RAM和I / O耗尽而臭名昭着。加速MSBuild构建的一般方法是“获得最佳机器资金可以购买”，特别是：

1. CPU - 至少两个Intel 3.0 GHz Core 2 Duo。

2. RAM - 至少4 GB DDR3。如果这是开发人员和构建计算机，则64位操作系统和8 GB RAM是更好的选择。

3. 硬盘 - 最快的选择是高端3ware RAID-1，带有板载电池和启用的写入缓存。快速SSD可能是另一个需要考虑的选择。

4. 网络 - 最低1 Gbit / s卡。

这种简单的硬件优化可以将您的MSBuild加速2-3次。

Answer 4

如果你有足够的RAM并使用Visual C ++（不确定C＃），你可以通过将整个include和lib目录复制到RAM驱动器来加速。

您还可以将临时构建项目放在RAM驱动器上。当然你需要大量的RAM。对于包含和库，2 GB RAM驱动器就足够了。但对于临时文件（* .obj等），它将取决于项目。所以它可能在1到4 GB之间或更多。