1

To compile my current project, one exe with ~90,000 loc + ~100 DLL's it takes about a half hour or more depending on the speed of the workstation.

The build process is one of running devenv from Powershell scripts. This works very well with no problems.

The problem is that it is slow. I want to speed up this build process.

MSBuild (using VS-2005) is one option but there's a bug specifying icons to the vb compiler/linker on the command line such that it won't successfully link.

What other options are there to "make" VB.NET programs?

(Faster workstation is not an option.)

4

5 回答 5

3

您是否每次都必须编译整个解决方案？有了这么多的程序集，除非它们真正改变，否则它们似乎不太可能都需要构建。如果您的解决方案由多个项目组成，您可能会考虑在构建环境中创建多个解决方案。一个主解决方案可以包含所有项目，另一个包含最常更改的项目。然后，您可以配置构建过程以专注于已更改的项目。根据您使用的源代码控制系统，您可能能够查询系统以确定自上次构建以来哪些项目已更改，并且仅构建这些项目。

于 2008-12-20T03:03:56.033 回答
1

如果可以，请升级到 3.5 版本的 MSBuild。它可以构建解决方案文件，并启用对多处理器支持的支持（或者如果您需要自己托管它），使其能够并行构建项目。

需要注意的是，您需要使用项目引用，以便它知道要构建什么。

还有，现在需要多长时间？您是否查看过 CPU/内存使用情况（使用类似PerfMon的东西）来查看它是否是瓶颈？

于 2008-12-20T03:10:00.563 回答
1

There's NAnt, and Cruisecontrol.NET for continuous build.

You mentioned that getting a faster PC is not an option, but how much memory do you have? 2GB should be the minimum for a developer machine. Also, using a fast 10K RPM hard disk makes a big difference.

Have you tried disabling any virus scanner during your build?

于 2008-12-20T02:05:48.740 回答
0

如果您有大量项目，那么您应该尝试减少它们。您以后可以随时将它们拆分为 dll。项目越少，构建的速度就越快。特别是如果它必须按特定顺序构建它们。

将它们分解为更小的解决方案也是一种选择。

于 2008-12-20T08:21:01.637 回答
0

除了为您的机器添加更多内核、CPU 能力和内存之外，您无能为力让构建过程更快，但这不是您的选择。

大多数大型项目都不是独立于单个 EXE 中的。更常见的是，逻辑单元被移动到单独的程序集中，这些程序集可以是 DLL 或 EXE。最终结果是一大堆小组件，而不是一个巨大的组件。

举一个例子，我参与的一个项目是巨大的，由 700 多个表格和 10 个类组成，其中 1000 个。功能相关的表单，例如与打印、报告生成、用户询问等相关的表单，都包含在自己的 EXE 中。如果我正在处理报告，我会从构建过程中排除所有与报告无关的项目，这有助于将编译时间从半小时缩短到几秒钟。

这种编程风格可能很棘手，但如果做得好，它就可以简单地工作并且完美无缺。

于 2008-12-20T05:52:49.143 回答