要编译我当前的项目，一个包含约 90,000 个 loc + 约 100 个 DLL 的 exe 大约需要半小时或更长时间，具体取决于工作站的速度。
构建过程是从 Powershell 脚本运行 devenv 的过程之一。 这工作得很好，没有任何问题。
问题是它很慢。 我想加快这个构建过程。
MSBuild（使用 VS-2005）是一种选择，但在命令行上指定 vb 编译器/链接器的图标时存在一个错误，因此无法成功链接。
还有哪些其他选项可以“制作”VB.NET 程序？
（更快的工作站不是一个选择。）
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.)
发布评论
评论（5）
您是否每次都必须编译整个解决方案？ 对于如此多的程序集，除非它们确实发生变化，否则似乎不太可能需要构建它们。 如果您的解决方案由多个项目组成，您可以考虑在构建环境中创建多个解决方案。 一个主解决方案可以包含所有项目，另一个主解决方案可以包含最常更改的项目。 然后，您可以配置构建过程以专注于已更改的项目。 根据您使用的源代码控制系统，您也许能够查询系统以确定自上次构建以来哪些项目已更改，并且仅构建这些项目。
Do you absolutely have to compile the whole solution every time? With that many assemblies it seems unlikely that they all need to be built unless they actually change. If your solution is made up of multiple projects, you might consider creating multiple solutions in your build environment. One master solution could contain all the projects, another that includes the ones that change most often. You can then configure your build process to focus on the projects that have changed. Depending on the source control system you use, you may be able to query the system to determine which projects have changed since the last build, and only build those projects.
有 NAnt 和 Cruisecontrol.NET 用于持续构建。
您提到购买更快的电脑不是一个选择，但是您有多少内存？ 对于开发者机器来说，2GB 应该是最小的。 此外，使用快速 10K RPM 硬盘可以使studio-performance.aspx" rel="nofollow noreferrer">差别很大。
您是否尝试过在构建过程中禁用任何病毒扫描程序？
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?
如果可以，请升级到 MSBuild 3.5 版本。 它可以构建解决方案文件，并支持 多处理器支持（或此处（如果您需要自己托管它）使其能够并行构建项目。
需要注意的是，您需要使用项目引用，以便它知道要构建什么。
另外，现在需要多长时间？ 您是否查看过 CPU/内存使用情况（使用类似 的内容PerfMon）看看是否是瓶颈？
If you can, upgrade to the 3.5 version of MSBuild. It can build solution files, and enables support for multiprocessor support (or here if you need to host it yourself) enabling it to build projects in parallel.
The caveat is that you need to be using project references so it knows what to build.
Also, how long is it taking now? Have you looked at the CPU/Memory Usage (using something like PerfMon) to see if it is a bottleneck?
除了向计算机添加更多内核、CPU 功率和内存之外，您无法采取任何措施来加快构建过程，但这在您的情况下不是一个选择。
大多数大型项目都不是独立于单个 EXE 中的。 更常见的是，逻辑单元被移动到单独的程序集中，这些程序集可以是 DLL 或 EXE。 最终结果是一堆小组件，而不是一个巨大的组件。
举个例子，我参与的一个项目非常庞大，包含 700 多个表单和数十个或数千个类。 功能相关的表单，例如与打印、报告生成、用户询问等相关的表单，都独立包含在自己的 EXE 中。 如果我正在处理报告，我会从构建过程中排除与报告无关的所有项目，这有助于将编译时间从半小时缩短到几秒钟。
这种编程风格可能很棘手，但如果做得正确，它就会简单地工作并且完美地工作。
There's not much you can do to make the build process any faster short of adding more cores, CPU power, and memory to your machine, but that isn't an option in your case.
Most large projects are not self-contained in a single EXE. More often, logical units are moved into seperate assemblies, which can either be a DLL or EXE. The end result is a whole bunch of little assemblies, instead of one enormous one.
To cite one example, one project that I worked on was enormous, consisting of 700+ forms and 10s of 1000s of classes. Functionally related forms, such as those related to printing, report generation, user interrogation, etc were self-contained in their own EXEs. If I was working on the reports, I'd exclude all projects not related to reports from the build process, and this helps bring the compilation time down from a half hour to a few seconds.
This programming style can be tricky, but when it done right, it simply works and works flawlessly.
如果您有大量项目，那么您应该尝试减少它们。 稍后您可以随时将它们拆分为 dll。 项目越少，构建速度就越快。 特别是如果它必须按照一定的顺序构建它们。
将它们分解成更小的解决方案也是一种选择。
If you have a big number of projects then you should try to reduce them. You can always split them up in dll's later. The fewer projects the faster it can build. Especially if it has to build them in a certain order.
Breaking them in smaller solutions is also an option.