ASP.NET 2.0的编译行为
【IT168 专稿】在从ASP.NET1.1向2.0迁移的时候在如何生成debug和release的构建(builds)方面做了调整.
1.1
在1.1的时候(对应的IDE是VS2003),在生成(build)菜单下面有一个配置管理器(Configuration Manager)的菜单项.点击这个菜单项会弹出一个对话框,你从中可以选择一些可用的构建配置.VS2003默认情况下提供了Debug和Release这两种配置.在配置管理器(Configuration Manager)中选择的配置信息可以告诉VisualStudio如何编译code-behind文件.成功编译后就会在bin目录中生成一个.dll文件(注:选择Release模式不会生成pdb文件),如果配置的时候需要生成调试符号(Debugging Symbols)的话,还会同时在bin目录中生成一个包含调试符号的后缀名为pdb的文件(注:选择Debug模式生成pdb文件).
稍后,当这个应用程序接收到一个web请求就开始执行时,ASP.NET运行时(runtime)就会为应用程序的web窗体 (web forms)和用户控件(user control)生成代码,并且编译生成的代码(这里的代码应该指的是MSIL代码).运行时的编译(JIT编译)将会根据web.config中compilation节中的调试设置(debug setting)来决定是否编译优化过的代码,是否生成调试信息.ASP.NET将把生成的结果放到临时ASP.NET文件目录中(Temporary ASP.NET file).在VS2003中只有选择Release模式并且同时在web.config中把debug设置为false才能产生真正的不带调试符号的产品.
2.0
在2.0中有一个非常重要的概念就是:VS2005并不知道编译一个web应用程序的任何信息(knows nothing).在1.1中visual studio构建code-behind文件,asp.net则负责构建web窗体.而在2.0中vs2005把所有的编译工作都交给了ASP.NET平台做.
有了这些概念后,这里有两种场景需要探讨:构建一个不带Web站点部署工程 的web应用程序和构建一个带Web站点部署工程的web应用程序.我们先看第一种,当你让Visual Studio构建一个web工程的时候,看起来好像什么都没有发生.你并没有发现在你的工程中创建了一个bin目录,里面有编译好的dll.这是因为现在是ASP.NET而不是Visual Studio来构建的.ASP.NET构建所有的的一切,包括.cs和.vb文件.ASP.NET把结果程序集放到Temporary ASP.NET files目录中,你可以自己打开看看.由于是ASP.NET负责所有的编译工作,所以web.config中间中complilation节的debug设置控制着当前应该是debug模式还是release模式.当debug设置为true的时候,你会发现生成程序集的同时会生成一个保存调试信息的pdb文件.这种新的编译模式使得对于一个web站点项目来说配置管理器已经过时了.在vs2005的配置管理器只能看到debug一个选项.不要着急,这不会有任何问题.实际上web.config中的debug设置控制着这些(和配置管理器没有什么关系).当你打算部署的时候,你可以发布这个网站,构建->发布(Build->Publicsh)将预编译整个web应用程序并且把结果保存在你选择的目录里.你也可以把它发布到IIS或者FTP上.当你选择发布(publish)命令的时候,你会看到一个对话框可以选择目标位置,强命名选项等等.这些选项和命令行工具aspnet_compiler中用到的一些开关是一一对应的.aspnet_compiler工具还提供了是否产生调试符号的开关,但是这个选项在发布(publish)对话框中是不可用的.发布总是预编译一个不包含调试信息的release版本.
0
相关文章