我们有许多编译.NET代码的Nant脚本。这些构建需要5到10分钟才能运行,我想找到一种方法来加速它们。
我们的Nant脚本看起来像
<target name="compile.XYZ" description="Compiles the source code">
<msbuild project="${src.dir}\XYZ.sln" verbosity="${build.verbosity}">
<property name="Configuration" value="${build.config}" />
<property name="OutputPath" value="${build.fullpath}/${prefix.xyz}" />
<property name="ReferencePath" value="${assembly.dir}" />
</msbuild>
</target>
他们都非常相似。我确实对nant进行了调查,但它看起来有点过时,所以我对使用它有点犹豫,虽然这可能非常方便,因为我们在构建中有多个目标。
您可以提供任何帮助来改善这些版本的性能,我们将不胜感激!
谢谢:)
答案 0 :(得分:4)
任何构建系统需要注意的一件事是确保它了解所有依赖项。在你的情况下,你正在混合构建系统,这很好,但你必须确保Nant和MSBuild都知道你的依赖。如果您有两个相互依赖的解决方案,那么将这些依赖项目移动到他们自己的解决方案中可能是有益的,以确保它们仅在构建周期中构建一次。
确保您正在利用渐进式编译。如果您不相信发布候选者的增量构建,则使用单独的构建目标来进行发布与测试和开发构建。还要确保对正在运行的构建类型使用适当的编译器设置。
任何彼此没有编译时依赖关系的解决方案都可以并行构建。虽然MSBuild(3.5及更高版本)natively支持在同一台机器上进行并行构建,但Nant却不支持(它的Java兄弟,Ant却这样做)。补偿这一点的一种方法是创建仅由构建使用的主解决方案文件。这将允许MSBuild并行化独立项目。这个稍微过时的MSDN article列出了不同解决方案/项目组织技术的优缺点。您可以通过设置构建服务器场并在多台计算机上构建独立解决方案来将其提升到新的水平。大多数持续集成服务器都支持此功能。
需要考虑的另一件事是您的项目是否遵循多个开发项目的DRY原则。如果两个不相关的项目具有类似用途的类,则可以将它们组合成一个类并移动到共享库。通过删除代码重复,您不仅可以降低维护成本,还可以同时优化构建过程。如果您的开发人员专注于某些项目,那么在不相关的项目中查找重复是非常耗时的。
答案 1 :(得分:3)
您的解决方案中的项目越多,构建所需的时间就越长。 与解决方案的数量相同。
你真的无能为力。 顺便说一句,这不是Nant在这里慢,它的msbuild。
你可以尝试Scott Hanselsman提出的一些建议:
http://www.hanselman.com/blog/FasterBuildsWithMSBuildUsingParallelBuildsAndMulticoreCPUs.aspx
实际上,这需要你将“BuildInParallel =”true“”传递给任务,尽管有一些警告。
这将允许同一解决方案中的项目并行构建,但我没有看到并行构建多个解决方案的方法。
为此,您可以制作元解决方案(仅在手动维护,或在构建完成之前在nant中自动生成),您可以在其中添加所有不同的项目。
答案 2 :(得分:1)
假设你有足够的内存,我会买一个RAM磁盘应用程序(我使用这个one效果很好)。
在此驱动器上安装源代码,安装Nant。在那里安装第三方库和其他支持基础设施。它应该产生至少33%到50%的跳跃。
此外,获取SSD并在其上安装操作系统和.NET框架。你应该能够一起进一步削减它。
答案 3 :(得分:1)
另一种方法是根据对代码的理解使MSBuild分离任务。 您可以使用/ m:x参数指定可以使用的CPU数量。或者只是/ m来使用所有。
一些链接供您阅读: