加快 ASP.NET 中的构建时间答案

【问题标题】：Speeding up build times in ASP.NET加快 ASP.NET 中的构建时间
【发布时间】：2010-10-20 18:44:57
【问题描述】：

我目前参与了一个 ASP.NET 项目，解决方案中有大约 40 个项目。我们在克隆的 Virtual PC 环境中进行所有开发，因此所有开发人员都有相同的设置。这一切都很好，管理依赖关系很容易，但是构建解决方案非常慢。 Virtual PC 只能使用一个 CPU，所以我实际上只使用了一半的计算机资源。

从构建到完整的页面加载需要整整 3 分钟。随着项目的增长，这种情况每天都在变得更糟。修复简单的事情开始需要很长时间，就个人而言，我一直在等待，因为我在计算机编译时无法真正工作。

有没有什么方法可以在多台计算机上分发我的构建以加快构建过程？

SSD 会显着缩短我的构建时间吗？

还有其他加快构建速度的方法吗？

注意：我曾尝试使用 ngen 预编译静态依赖项，但后来得知 ASP.NET 不支持 ngen。我使用 Visual Studio 2008，虚拟环境中没有防病毒软件。

【问题讨论】：

是构建时间慢，还是 ASP.NET 启动第一页需要很长时间？
两者，大约是 2/3 build 和 1/3 ASP.NET

标签： .net asp.net visual-studio-2008 msbuild build-process

【解决方案1】：

下面是另一个加快 ASP.NET 构建时间的技巧：

如果您有足够的内存，请创建一个 RamDisk 并将您的 ASP.NET 临时文件指向这个基于 ram 的磁盘。

【讨论】：

【解决方案2】：

您可以通过执行以下操作大大减少等待 ASP.NET 构建的时间：

使用新的“optimizeCompilations”标志。它会告诉 .NET 不要仅仅因为您更改了一个项目/dll 而重建整个项目。如果您有 40 个项目并且您不使用它，那么每次您在一个项目中更改一个简单方法时，.NET 都会尝试编译所有其他项目和 dll。使用新标志（加上安装修补程序），您将在开发过程中看到整体性能大幅提升。

【讨论】：

从 Windows 7 开始，您无需安装修补程序即可使用“optimizeCompilations”标志。 .NET Framework 4.0 也可以使用相同的功能。但是，使用此标志是一种激进的选择，应仔细考虑。在大多数情况下它是有帮助的，但它也有一些缺点。看这篇帖子msdn.microsoft.com/en-us/library/ms366723.aspx（“动态编译的缺点”一节）了解一下。

【解决方案3】：

我们公司所做的是使用文件引用，因此只需要构建更改的项目，并且在任何给定时间，我的解决方案中的项目不超过 10 个，主要是构建 2~3 个。

我们还为每次签入构建主干，并为开发人员提供批处理文件以提取最新的 dll。

当然，这并不能阻止令人痛苦的程序集引用错误的发生，但一段时间后它们变得比问题更令人讨厌。

【讨论】：

【解决方案4】：

不要在您的解决方案中放置这么多项目。仅当代码在不同进程或不同机器上运行时才创建新项目。在大多数情况下，创建这么多项目是没有用的。项目数量是 msbuild 中最显着的减速。

【讨论】：

没错，这似乎是相关的。如果我有时间，我可能会尝试减少项目数量，但我怀疑管理层是否愿意这样做。这是一个相当大的系统，有几个不同的组件和多个抽象层。它们不可能都在同一个项目中。
层是否在多个物理层上运行？
但是，您可以将项目组合并到相关的解决方案中。这意味着您需要不时切换解决方案或使用多个 VS 实例，但这更易于管理。
有一些项目在不同的机器上作为单独的 Web 服务运行，但它们已经在自己的解决方案中。但是我从事的大多数项目，以及一些我不从事的项目，都共享我经常修改的常见较低级别。因此，我必须全部构建它们以确保在修改界面时不会破坏任何东西.
在这种情况下，我会尽可能合并项目。制作 20 或 10 个项目而不是 40 个项目将为您节省超过 50% 的构建时间。

【解决方案5】：

您也可以考虑切换到使用多个处理器的 VMware Workstation。我目前正在使用具有两个双处理器 VM 的设置，并且所有四个都可以使用。

【讨论】：

【解决方案6】：

您是否尝试过调整虚拟 PC？

http://www.windowsnetworking.com/articles_tutorials/Tuning-Virtual-PC-Performance.html

老文章，但大意仍然正确。

我发现，在类似的情况下，为 VPC 磁盘映像配备一个单独的硬盘可以显着提高性能，尤其是在消除一些限制时。

也许问题不在于 Visual Studio，而只是编译是资源密集型的。

【讨论】：

映像从单独的碎片整理驱动器运行，我有一个双核系统。当编译单个虚拟 CPU 在整个构建过程中几乎达到 100% 的使用率时......而不是硬盘驱动器。
你说的“单虚拟CPU”是指虚拟机内部的CPU还是父机器上的单核？
哦，对不起，那里的措辞可能很糟糕。我的意思是虚拟机内部的 CPU。
有可能在 VPC 配置中您没有允许它使用所有 CPU？除此之外，也许考虑对 VMware 和 VirtualBox 进行测试，它们都可以挂载其他虚拟化平台的驱动器映像，因此值得研究。 VmWare 当然可以让您使用多个内核，而且同样免费。

【解决方案7】：

Scott Gu 有一篇非常有用的帖子：

Tip/Trick: Optimizing ASP.NET 2.0 Web Project Build Performance with VS 2005

Scott 也有另一篇关于这个硬盘的速度的文章，这对 Visual Studio 的一般性能也有影响：

Tip/Trick: Hard Drive Speed and Visual Studio Performance

【讨论】：

另一个需要注意的是反病毒正在设置以扫描读/写文件。我发现将我的工作文件夹从 AV 按访问扫描中排除是有利的。
@thedorko - 我同意，Scott Gu 在我链接到的第一篇文章中确实解决了这个问题（除其他事项外）。

【解决方案8】：

我们也遇到过类似的情况，我发现我们的虚拟机受到严重限制，因此虽然它们都运行在单个 CPU 上，但不允许它们充分利用该 CPU。我设法让 3 个虚拟机在一个物理机上运行，以使它们的运行速度提高 100%。

我还会考虑尝试减少您的项目数量。我们的主要解决方案有 40 个项目，我一直在慢慢整合这些项目，并确保新开发项目尽可能适应现有项目。造成这种情况的主要罪魁祸首是 web 服务，每个服务最初都是在一个单独的项目中创建的。我现在正在将所有新的 Web 服务添加到一个项目中，并慢慢地移动其他的。

【讨论】：

【解决方案9】：

您没有提及您的 Visual Studio 版本，但如果是 2005 年，您可能需要考虑升级到 2008 年。就我而言，这减少了大型（30 多个项目）解决方案的构建时间。

另一种选择是预先构建一些不再更改的库并引用已编译的 dll 而不是项目。

【讨论】：

我使用 VS 2008。预构建并没有太大帮助，因为我们不再更改的唯一项目很小，而且可能构建速度很快。

【解决方案10】：

是否每次都需要重建全部 40 个项目。

您可以在解决方案配置设置中配置生成的内容。

即如果您的更改仅在您的 WebUI 项目中，而其他 39 个项目未更改，您可以创建一个构建配置，其中仅重新构建您的 Web 应用程序。

查看配置下拉菜单
点击“配置管理器”
在“活动解决方案配置”下拉菜单中单击“新建”
创建一个从调试配置复制的新配置
在您的新配置中，取消选中所有项目构建，但您已更改的项目除外

【讨论】：

如果低层项目没有任何变化，msbuild 足够聪明地意识到没有任何变化并且不会重新构建它们。当您对要重新编译的文件进行更改时，它将重新编译自身及其所有依赖项。
但是我怎么知道我没有破坏那些我不构建的项目中的构建呢？
您只构建项目“高于”您在依赖项链中更改的项目...如果您有 39 个 DLL 项目，这些项目在您的 Web 应用程序中引用，并且您只更改您的 Web 应用程序，那么更改不会向下破坏任何内容。
我通常在多个层进行更改，因为该项目正在积极开发中，每次我要在较低级别进行更改时重新配置构建配置似乎是自找麻烦。