要编译我当前的项目，一个exe用~90,000 loc + ~100 DLL，大约需要半小时或更长时间，具体取决于工作站的速度。
构建过程是从Powershell脚本运行devenv之一。这很好用，没有任何问题。
问题是它很慢。我想加快这个构建过程。
MSBuild（使用VS-2005）是一个选项，但是在命令行上为vb编译器/链接器指定图标时会出现错误，导致它无法成功链接。
“make”VB.NET程序有哪些其他选择？
（更快的工作站不是一个选项。）
答案 0 :(得分：3)
你每次都必须编译整个解决方案吗？有了这么多组件，它们似乎不太可能都需要构建，除非它们真正改变。如果您的解决方案由多个项目组成，您可以考虑在构建环境中创建多个解决方案。一个主解决方案可以包含所有项目，另一个包含最常更改的项目。然后，您可以配置构建过程以专注于已更改的项目。根据您使用的源控制系统，您可以查询系统以确定自上次构建以来哪些项目已更改，并且只构建这些项目。
答案 1 :(得分：1)
持续构建NAnt和Cruisecontrol.NET。
您提到获得更快的PC不是一种选择，但您有多少内存？ 2GB应该是开发人员机器的最低要求。此外，使用快速10K RPM硬盘会产生big difference。
您是否尝试在构建期间禁用任何病毒扫描程序？
答案 2 :(得分：1)
如果可以，请升级到3.5版本的MSBuild。它可以构建解决方案文件，并支持multiprocessor support（或here如果您需要自己托管它），使其能够并行构建项目。
需要注意的是，您需要使用项目引用，以便知道要构建的内容。
此外，现在需要多长时间？您是否查看了CPU /内存使用情况（使用PerfMon之类的内容）来确定它是否是瓶颈？
答案 3 :(得分：0)
除了为您的计算机添加更多内核，CPU电量和内存之外，您无法做更快的构建过程，但在您的情况下这不是一个选项。
大多数大型项目都不是单个EXE中的自包含项目。更常见的是，逻辑单元被移动到单独的程序集中，这些程序集可以是DLL或EXE。最终的结果是一大堆小装配，而不是一个巨大的装配。
举一个例子，我参与的一个项目非常庞大，包括700多种形式和10种1000种类。功能相关的形式，例如与打印，报告生成，用户询问等相关的形式，在它们自己的EXE中是独立的。如果我正在处理报告，我会排除与构建过程中的报告无关的所有项目，这有助于将编译时间从半小时缩短到几秒钟。
这种编程风格可能很棘手，但如果做得恰到好处，它就能完美无缺地运作。
答案 4 :(得分：0)
如果您有大量项目，那么您应该尝试减少它们。您可以随后在dll中将它们拆分。项目越少，构建的速度就越快。特别是如果它必须以某种顺序构建它们。
在较小的解决方案中打破它们也是一种选择。