ASP.NET 预编译命令（解决发布后第一次访问慢问题）

ASP.NET 编译工具 (Aspnet_compiler.exe) 官方说明

新建bat文件

1.  
   @echo off
2.  
   CD /d C:\Windows\Microsoft.NET\Framework\v2.0.50727
3.  
   aspnet_compiler -p E:\wwwroot\站点主目录 -v /
4.  
   echo 命令执行成功！
5.  
   pause

请注意，上面的v2.0.50727代表项目的.NET版本，可根据项目版本替换成以下版本

v2.0.50727

v3.0

v3.5

v4.0.30319

每次发布新版本后，执行下此bat文件即可完成预编译，并且会自动检测提示异常

---

DUDU:

为什么要用预编译？

博客园博客程序中.aspx和.ascx文件总共加起来有3000多个（博客模板中有大量的.ascx文件）。如果使用动态编译，每次只要更新bin文件夹中的任何一个dll文件，动态编译至少需要5分钟（访问量越高，所需的编译时间越长），而在动态编译期间网站访问速度极慢，几乎就是无法正常访问。这样，每次更新程序成为了一种痛苦，只能安排在深夜或一大早。

面对这样的情况，只能选择预编译。

预编译的原理是什么？

请阅读Artech写的深入剖析ASP.NET的编译原理之二：预编译（Precompilation）。

如何进行预编译？

用aspnet_compiler命令，命令示例：

aspnet_compiler -v \ -p G:\SourceWebSite G:\TargetWebsite -fixednames

参数说明：

-v \  要编译的虚拟路径，这里表示根路径。

-p G:\SourceWebSite 要编译的源Web项目所在文件夹。

G:\TargetWebsite 编译目标文件夹。

-fixednames 每个.aspx与.ascx文件都编译生成单独的dll文件，并使用固定文件名。

编译情况分析

1. 源文件夹中的所有.aspx, .ascx及App_Code中的.cs文件都会被编译。

2. 编译中遇到任何一个错误，会立即停止编译，并清空目标文件夹中已生成的文件；解决了引起编译错误的问题后，只能从头重新进行编译。出现编译警告，只提示，不影响正常编译。

3. 编译完成后，aspnet_compiler会将.aspx, .ascx, .cs之外的所有文件原封不动地复制至目标文件。（如果编译只是为了更新网站程序，这个操作显得多余。aspnet_compiler没有提供取消这个操作的参数）

4. 3000多个.aspx,.ascx文件，使用-fixednames编译，耗时30分钟左右；不使用-fixednames编译，只要6分钟。-fixednames编译本来是为了更新方便（每次编译生成的文件名相同，更新生产环境中的dll时直接覆盖就行），没想到这么慢。不用-fixednames编译，每次更新时，要先删除原来的文件，再复制。在生产环境中，这个操作会短暂影响网站的正常访问。

5. 预编译不会生成任何.ascx文件，也就是编译目标文件夹中没有任何.ascx文件。如果存在通过System.IO.File.Exists判断.ascx文件是否存在的代码，将不能按正常逻辑执行。解决方法是将.ascx文件复制到目标文件夹。

为什么不用“可更新的预编译(Updatable Pre-compilation)”

Updatable Pre-compilation只编译App_Code中的文件以及.aspx,.ascx的code behind文件，我们的Web项目类型是Web Application，code behind已经编译了，App_Code中也没有代码，相当于已经处于这种编译状态，但还是需要至少5分钟的动态编译时间。

这种编译方式只是减少了编译.cs文件的工作量，但每个.aspx,.ascx文件还是要动态编译，不能避免动态编译的性能问题。

Updatable Pre-compilation适用于App_Code中有大量代码（更新其中的文件会引起该文件夹中的所有文件重新编译），又不想用Non-updatable Pre-compilation的情况。

结论

面对这么多的.aspx,.ascx文件，只能选择预编译。-fixednames编译实在太慢，只能放弃。更新时只能先删除，再更新。虽然有些不足，但总比动态编译好。

当然，真正的解决之道是干掉模板中的那些.ascx文件。ASP.NET MVC会是救星吗？