asp.net - ASP.NET 网站项目在编译时是否天生就很慢，或者我可能有更深层次的问题？

Question

一段时间以来，我一直在客户端处理旧版 ASP.NET 网站（相对于 Web 应用程序）项目，其缓慢的编译时间让我想知道：

是否已知网站项目在编译时（比 Web 应用程序项目）慢（呃）？

这是一个很小的网站，但整个解决方案有大量的功能——值得拥有 19 个项目，其中 18 个编译速度非常快（非 Web 项目）。网站项目本身有大约 100 个页面和大约 15 个用户控件（这些实际上需要大约一半的编译时间）并且通常在 30 到 60 秒内编译。完整的重建需要更接近后者。

所以，我认为有些事情可能会减慢它的速度（你揭穿它们）：

(X)HTML 验证问题（我们继承的代码有数千个关于验证问题的编译器警告）。
高层次的抽象——因为网站页面的代码是在运行时编译的，我猜想无论它为用户控件所做的一切都是一个漫长的过程，因此编译时的绑定可能会发生。
网站的大小？我知道这些不是非常有效的项目，相信我，我已经花了几个小时试图将其转换为 Web 应用程序，但 Visual Studio 无法将单个 ASPX 文件解析为其 .aspx/.designer.xx 组件，因为我之前提到的验证问题。

假设我的客户不会批准超过几个小时来解决这个问题，是否有任何已知的快速修复、更改或优化可以帮助我？

我没有一台微不足道的电脑，所以它的处理能力不是问题。我还参与过大小和复杂性相当的 Web 应用程序项目，这些项目只需几秒钟即可编译。

我对几乎任何事情都持开放态度，所以我很想听听你的想法！另外，如果您认为这应该是一个 wiki，请告诉我。

score 4 · Accepted Answer

我的观察结果是一样的：网站项目需要一段时间来构建，比网络应用程序项目更长。我想我找到了一些有关原因的信息，请查看：http: //msdn.microsoft.com/en-us/library/aa730880 (VS.80).aspx

搜索“迭代开发”。与 Web 应用程序项目相比，它是关于网站项目的：

默认情况下，每当您运行或调试任何页面时，Visual Studio 都会完全编译网站项目。这样做是为了识别站点中任何地方的编译时错误。但是，完整的站点构建会显着减慢迭代开发过程，因此通常建议您更改构建项目选项以在运行或调试时仅编译当前页面。

score 3 · Accepted Answer

提出的要点：

另一个可以帮助您的选项是切换到 RAM 磁盘：从 RAM 磁盘运行开发 - 选项和产品

如果这没有帮助，也许将您的大型 WAP 拆分为多个 WAP 可以缩短编译时间。不幸的是，该策略要求您放弃在 Cassini 上进行开发。相反，您将不得不使用 IIS 作为主机：在一个解决方案中使用多个 Web 应用程序项目 (WAP)

score 1 · Accepted Answer

大多数开发人员在 ASP.NET Web 项目中忽略的一个事实是App_Code文件夹中的类数量。
你放入的类越多，编译时间就越长。

从MSDN 上的 ASP.NET 编译概述：

ASP.NET 为每个应用程序目录（例如 App_Code）创建一个程序集，并为主目录创建一个程序集。（如果目录中的文件使用不同的编程语言，则将为每种语言创建单独的程序集。）

所以，如果你基本上可以最小化文件夹层次结构并减少其中的类数量，它可能会减少编译时间。

我从您的帖子中注意到的另一件事是，您有 18 个非网站项目。
我认为这有点过分了，因为这样想。

当 Web 项目编译开始时，ASP.NET 编译器需要链接 18 个单独的 DLL 文件。
如果可以组合这些项目以减少 DLL 的数量，它也可能会有所帮助。

从可维护性的角度来看，拥有 18 个项目有点过分，除非有非常充分的理由这样做。
我建议审查这些项目并将它们结合起来。

我希望它有所帮助。

score 0 · Accepted Answer

这可能并不理想，但您可以将项目拆分为多个解决方案。例如，您可以将用户控件放入解决方案 A 并将其余项目放入解决方案 B。然后在解决方案 A 中编译控件并从解决方案 B 中对它们进行文件引用，这将有助于减少编译时间

score 0 · Accepted Answer

网站或 web 项目，编译阶段后的性能应该相似。如果问题是在部署一组新代码后立即出现性能不佳，我能想到的一种快速方法是预先发布该站点。（参见参考资料http://msdn.microsoft.com/en-us/library/1y1404zt(VS.80).aspx）

根据您在发布期间选择的选项，您可能缺乏动态进行更改的灵活性（无论如何您都不应该这样做）。

5 回答 5