ASP.NET 2.0的编译方式大体可以分成两种：动态编译和预编译，要回答为什么要进行预编译，我们先要看看动态编译有什么不好的地方。我们回顾一下上一篇介绍的ASP.NET进行动态编译的简单的流程：当来自Brower的一个基于aspx的Http request抵达Web server，IIS handle这个request，通过分析注册在IIS中的Application Mapping，将Request 传给aspnet_isapi.dll ISAPI extension。ISAPI extension通过HttpRuntime进入Http Runtime Pipeline，HttpRuntime为每个Request创建一个单独的HttpContext对象，用于保存request的Context信息。在Http Runtime Pipeline中，Http request会被注册的一系列的Http module处理，比如OutputCache Module，Session Module，Authentication Module，Authorization，ErrorHandler Module等等。在Pipeline的终端，ASP.NET需要需要根据request创建对应的HttpHandler对象来处理该Request，并生成结果Response到Client。对于一个基于Aspx的Http request，对应的Http handler对象一般就是一个System.Web.UI.Page对象。

ASP.NET会先判断对应的Page type是否存在于被Cache的Assembly中，如果存在，直接创建Page对象，否则ASP.NET会先对该Page的相关的Source code (包括code behind，html等等) 进行编译，我们也说过这种编译是一Directory为单位的，也就是说，处于同一个Directory下的需要编译的文件会被编译成到同一个Assembly中。编译生成的Assembly会被Cache，用于后续的Request。

正是因为对资源的首次访问会导致一次编译（这样说不太准确，因为动态编译是以directory为单位进行的，应该对对某个Directory下的资源进行首次访问），这样会严重降低Web Application的响应速度。所以我们为了避免这种情况，需要预先对web site进行编译，所以提高web site的响应是进行预编译的最重要的原因。

同时动态编译就以为着Web server上放置的是Source code，而且他们是可被修改的。而对于一个开发完毕的Web Application，我们更希望以Binary Assembly的方式进行部署，这样Server上部署的都是Binary Assembly，不怕被别人篡改而导致系统的崩溃，从知识产权来讲，也更利于保护商业秘密。这也是我们为什么要进行预编译的另一个原因。

下面我们就来讲讲如何进行预编译，以及与编译背后的原理。

In Place Pre-compilation V.S. Pre-compilation for Deployment

对于预编译，有可以分为In Place Pre-compilation和Pre-compilation for Deployment，In Place Pre-compilation很简单，实际上就是把整个Web site编译到我们一个临时的目录下面，这个临时目录也就是我们在介绍动态编译提到的那个临时目录。而且这个编译的方式，包括生成的文件也和动态编译完全一样，唯一不同就是编译的时间：预先编译，编译的范围：整个Web site。这种编译就是你常用的在VS的build。这种编译方式一般用于开发阶段。

为了部署为目的的编译是我们今天讨论的重点，下面我们就着重来讨论Pre-compilation for Deployment。

注：在ASP.NET的编译都是通过一个叫做aspnet_compiler的工具执行的，该工具随ASP.NET 2.0一起发布，你完全可以利用此工具以命令行的方式的执行编译，并通过传递不同的命令行开关设置不同的编译选项。该工具被置于了VS中，使你可以利用VS进行可视化的编译。

Non-updatable Pre-compilation V.S. Updatable Pre-compilation

ASP.NET 2.0为我们提供了几种不同方式的预编译和部署。为了弄清楚这些预编译和部署方式，我们先来回顾一下ASP.NET 1.x下的编译方式。我们知道在ASP.NET 1.x时代对整个Web site进行编译，实际上我们只会对所有C#和VB.NET等后台代码进行编译，并生成一个单一的Assembly。而Web page的aspx是不会参与编译的。所以当我们访问一个Web page的时候，ASP.NET必须对aspx进行动态编译。

这一切之所以能够进行是因为Web page采用的是aspx + code behind的模式。

   1: <%@ Page Language="C#" AutoEventWireup="false" Codebehind="Default.aspx.cs" Inherits="Default" %>

   1: public partial class Default : System.Web.UI.Page
   2: {
   3:     protected void Page_Load(object sender, EventArgs e)
   4:     {
   5:         //...
   6:     }
   7: }

从上面我们可以看到aspx和Code behind是一种继承的关系，aspx继承和它对应的Code Behind。ASP.NET可以把Code behind和aspx分开进行编译，把它们编译到不同的Assembly中。我们就是上面的Code为例，我们现在若对该Web site进行编译的话，Default.aspx.cs会被编译到一个Assembly中，假设这个Assembly为App_Web.dll. 我们把该Dll和aspx部署到Production Server上。如果我们现在访问defaut.aspx。ASP.NET会对aspx进行动态编译，生成的Assembly可以暂时成为App_Web_aspx.dll。对于Default.aspx，如果我们如C#代码来描述的话，应该像下面一样定义：

   1: public class default_aspx:Default
   2: {
   3:      //...
   4: }

这种编译方式，我自己把它叫做对asXx的动态编译。在ASP.NET2.0 中也沿用了这种编译方式。这种编译方式的主要特征是对Code behind和所有的后台代码进行预编余，aspx（确切地说应该是asXx：asax，asmx，asax等）原样部署。由于这种方式的预编译，asXx是可以修改的（当然这种修改是有一定限制的，因为code behind已经编译好了，所以这种修改只可能是和code behind无关的修改），所以又叫做Updatable Pre-compilation。

除了Updatable Pre-compilation之外，ASP.NET还提供另外一种高效的预编译方式，Non-updatable Pre-compilation，之所以叫做不可修改的预编译，这是因为：这种编译方式把asXx、Code behind、后台代码甚至是部分Resource都进行预编译，从而避免了运行时对asXx的动态编译，从而最大程度地提高了整个Web site的响应。在部署的时候，我们除了把生成的Assembly进行部署之外，所有的通过编译生成的asXx也必须进行部署。 不过需要特别说明的是，此时的asXx文件仅仅是一个占位的文件而已，它里面不具有任何HTML。

Partial class

在ASP.NET 1.x，由于采用的aspx + code behind的机制，对于任何一个Web page或者其他ASP.NET 基于axXx的对象来说，都是由两个文件、两个class组成。两个文件是指axXx和code behind，两个class是指Code behind定义的继承自System.Web.UI.Page的class，和一个继承自它的由axXx生成的class。

对于使用过ASP.NET 1.x来说，一定会很熟悉这样一种情况：对于每个在aspx中通过HTML定义的Server Control，在Code behind中必须具有一个对应的protected成员，否则你不能通过编程的方式访问这个Server control。以不同方式呈现的同一个Server control通过ID关联起来，如果在Code behind中改了Server control的ID，Server control的Server端的Event handler将会失去原有的作用。

但是在ASP.NET 2.0来说，这种情况发生了改变，在aspx中的Server control在Code behind中却没有相应的成员变量，但是我们可以毫无障碍地访问到每个Server control。这使得我们的code behind更加简洁，通过避免了Server control在aspx和code bebind中的不匹配的问题。这一切都得益于.NET Framework 2.0提供的partial class的机制：把同一个class分布于不同文件中进行定义。有了这个概念，我们来看ASP.NET 2.0的code behind机制。比如我们有这样的一个Page：

   1: <%@ Page Language="C#" AutoEventWireup="true" CodeFile="Default.aspx.cs" Inherits="_Default" %>

   2: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

   3: <html xmlns="http://www.w3.org/1999/xhtml" >

   4: <head runat="server">

   5:     <title>Default</title>

   6:     <link href="Style.css" rel="stylesheet" type="text/css" />  

   7: </head>

   8: <body>

   9:     <form id="form1" runat="server">  

  10:     <div>          

  11:            <asp:Button runat="server" ID="btnRefresh" Text="Refresh" OnClick="btnRefresh_Click" />   

  12:     </div>

  13:     </form>

  14: </body>

  15: </html>

Code behind如下：

   1: public partial class _Default : System.Web.UI.Page

   2: {

   3:     protected void Page_Load(object sender, EventArgs e)

   4:     {

   5: }

   6:     protected void btnRefresh_Click(object sender, EventArgs e)

   7:     {

   8:         this.Response.Write("The click event of \"Refresh\" button is fired");

   9:     }

  10: }

而实际上，ASP.NET会为我们创建一个隐藏的.cs文件（这个文件有人 把它称之为Sibling partial class）：

   1: public partial class _Default: IRequiresSessionState

   2:   {

   3:     protected Button  _ btnRefresh;

   4:   }

这个文件会随着aspx文件的改变而动态变化，所以code behind中的Server control永远和aspx中的Server control是完全匹配的。所以我们说ASP.NET 2.0的Page是由3个文件、两个class组成的。

编译的粒度和Assembly的命名

到现在为止，我们所讲的ASP.NET的预编译都是以Directory为单位的，同一个Directory下的所有需要编译的文件被编译到同一个Assembly中。ASP.NET还支持以Page为单位的预编译，也就是每个Page编译成一个Assembly。

在默认的情况下，ASP.NET预编译生成的Assembly名称是随机生成的，也就是每次生成的Assembly都具有不同的name。所以我们在部署Web site的时候，一般需要把原来的Assembly删掉，再部署新的Assembly。不过ASP.NET为我们提供了另外一种选择，使得每次编译生成的Assembly具有相同的名称，这样我们部署的时候就可以直接把新的Assembly　拷贝到Production Server上，自动覆盖掉同名的Assembly。