预编译选项
在首次启动应用程序的时候,ASP.NET会动态地分析和编译所有的ASP.NET文件(aspx页面)。运行环境要对编译的结果进行缓冲,以便更好地服务未来所有的请求。
在 服务器 重启或者Web 服务器 重启之后,第一次启动应用程序也意味着这一过程要重新开始。而且,对应用程序任何文件的改变都会被系统检测到,而在文件发生改变之后首次运行应用程序也会让这一过程再次发生。
很多Web开发人员都很讨厌这种初始化延迟。而预编译通过(预先)编译应用程序避免了这种延迟。
命令行
通过安装在.NET框架2.0里的aspnet_compiler.exe程序就能够启动预编译。它位于框架安装目录下(版本号会根据安装的框架的版本而有所不同)。下面就是这个程序默认的路径:
C:<windows base directory>Microsoft.NET
Frameworkv2.0.5072aspnet_compiler.exe 您可以用-?这个命令参数查看该程序的所有参数列表,下面我就解释一下一些可用的参数:
- m:这个参数表示您将使用完整的、应用程序将被预编译的IIS元数据库路径。IIS元数据库的路径是/LM/W3SVC/1/Root/应用程序名。
- v:使用需要预编译Web应用程序的虚拟IIS路径。虚拟路径的格式是:/应用程序名。
- p:使用需要预编译Web应用程序的物理IIS路径。它是包括驱动器名和指向应用程序目录的完整路径。举个例子c:inetpubwwwroot应用程序名。v这个参数必须和p一起用,所以编译器能够解析任何应用程序的根参考。
- f:表示目标目录是否要被覆盖。
- u:用来设置预编译完的应用程序是可以更新的。这表示所有的标记文件(ASPX、ASCX等等)都可以在目标目录里进行更新。
- targetDir:用于预编译应用程序文件的目标目录。下面的命令用虚拟路径和指定的目标路径预编译了一个应用程序:aspnet_compiler.exe –v /应用程序名 c:目标目录名。
c: Windows Microsoft.NETFramework
v2.0.50727Temporary ASP.NET Files应用程序名 预编译另外一个好处是能够捕捉在应用程序启动阶段发生的任何错误。错误会显示在工具里,但是不会终止编译过程。
隐藏源代码
预编译的另外一个副产品是能够隐藏任何或者所有的应用程序源代码。这意味着其他的开发人员需要利用反编译程序或者ilasm才能够取得您的代码。这就行了——预编译让您能够以二进制文件的形式分发应用程序。
目标目录里没有源代码。App_Code文件夹里的所有类都被编译成一个或者多个二进制文件,放到bin目录下;目标目录下不会有源代码文件(.cs、.vb、.js等等)。此外,所有的主页面文件也会被编译到bin目录下,作为隐藏文件。ASPX、ASCX和ASHX文件的所有代码和标记,以及相关的代码隐藏文件都被放在bin目录下的一个或者多个程序集里。
隐藏源代码是毁誉参半。其他的开发人员无法以任何形式查看或者更改应用程序——即使是Web页面标记也不行。而另外一方面,对应用程序的任何改变(不论大小)都要求改变原始的源代码、重新编译和重新部署。这可能是一个十分耗时的过程,所以并不一定适用于所有的应用程序。
可更新命令参数(u)让您能够取代这个默认的行为。使用这个参数意味着所有的标记文件(ASPX、ASCX等等)都要包括在预编译过程的输出里。一旦应用程序被部署,这些文件仍然能够用于编辑和更新。在应用程序被应用之后,小的布局问题可以通过源文件来处理,所以这是一个非常理想的参数。
Visual Studio的支持
在使用Visual Studio 2005开发基于ASP.NET的应用程序时,预编译是可选的。“发布Web站点(Publish Web Site)”菜单选项让您能够把网站作为一个预编译应用程序推到另一个位置。此外,上面还有一个复选框让您设置可更新选项。
总结
ASP.NET 2.0的预编译选项让您能够预编译Web应用程序,以避免(像一般编译一样)首次调用应用程序的延迟。此外,它还提供了一定的安全性,因为程序的源代码在结果中是不可见的,所有的内容文件都可以被隐藏。
关于ASP.NET预编译
如何进行预编译?
用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会是救星吗?