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

Question

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

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

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

所以，我认为有些事情可能会减慢它的速度(你揭穿它们):

(X)HTML 验证问题(我们继承的代码有数千个关于验证问题的编译器警告)。

高层次的抽象——因为网站页面的代码是在运行时编译的，我猜想无论它为用户控件所做的一切都是一个漫长的过程，因此编译时的绑定(bind)可能会发生。

网站的大小？我知道这些不是非常有效的项目，相信我，我已经花了几个小时试图将其转换为 Web 应用程序，但 Visual Studio 无法将单个 ASPX 文件解析为其 .aspx/.designer.xx 组件，因为我之前提到的验证问题。

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

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

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

Answer 1

首先阅读这篇博文Tips to optimize design-time build performance for Web Sites in Visual Studio 2005

提出的要点:

不要禁用批处理编译

利用服务器端编译

将 App_Code 文件移动到单独的类库项目中

检查冲突的依赖关系

在 Windows 窗体设计器选项中关闭 AutoToolboxPopulate。

禁用对 HTML 编辑的验证

另一个可以帮助您的选项是切换到 RAM 磁盘: Running development from a RAM disk – options and products

如果这没有帮助，也许将您的大型 WAP 拆分为多个 WAP 可以缩短编译时间。不幸的是，该策略要求您放弃在 Cassini 上进行开发。相反，您必须使用 IIS 作为主机: Using multiple Web Application Projects (WAP) in one Solution