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