详解ASP.NET动态编译 |
本文标签:ASP.NET动态编译 1.动态编译的过程 我们先来介绍在ASP.NET动态编译下的大体的执行流程:当ASP.NET收到一个基于某个page的request的时候,先判断该Page和相关的Source code是否编译过,如果没有就将其编译,如果已经编译,就是用已经Load的Assembly直接生成Page对象 。 在这里有下面几点需要注意: 1). ASP.NET动态编译是按需编译的,ASP.NET只会编译和当前Request相关的aspx和code 。 2). ASP.NET动态编译是基于某个目录的,也就是说ASP.NET会把被请求的page所在的目录的所有需要编译的文件进行编译,并生成一个Assembly 。 3). 除了编译生成的Assembly外,动态编译还会生成一系列的辅助文件 。 4). 对相关文件的修改,会导致重新编译,但是修改对当前的Request不起作用 。也就是说如果你对某个aspx进行修改,那么对于修改后抵达的Request,会导致重新编译,但是对于之前的Request使用的依然是原来编译好的Assembly 。 5). 编译生成的文件被放在一个临时目录中,这个目录的地址为Windows Directory\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files 。其具体的目录结构如下图所示: 在Temporary ASP.NET Files下的Artech.ASPNETDeployment是IIS中Virtual Directory的名称,以下两级目录的名称由Hash value构成,所以编译生成的文件就保存在c6f16246目录下 。这个目录你可以通过HttpRuntime.CodegenDir获得 。 Directory\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files只是一个默认的临时目录,你可以在web config中的compilation section中设置你需要的临时目录 。
2.Sample 现在我用一个Sample来一探ASP.NET是如何进行动态编译的 。 在这个Sample中,我建立了一个Website,在根目录下创建了两个Page:Default和Default2 。 在两个子目录Part I和Part II下分别创建了两个Web page:Page1和Page2 。在App_Code目录中创建了一个Utility的static class 。下面是它的定义:
内容很简单,对当前加载的所有相关的Assembly(这些Assembly的Fullname以App_Web打头)进行Reflection,列出所有的Type 。这个ReflectAllAssmebly将在5个Web page(Default Page和两队Page1&Page2)的Page_Load事件中被调用 。
Default是列出所有4Page对应的Link以便我们访问它们,在我们再进行编译的情况下在IE中输入对应的URL来访问Default Page 。(其他Page的Html中不具有真正的内容,是一个空的page.) 通过上面的显示,我们可以看到现在有一个Assembly:App_Web_wh7-uda5 。该Asssembly定一个的Type有5个, _Default和 default_aspx分别对应Default Page,而Default2和 default2_aspxDefault2 Page的 。FastObjectFactory_app_web_wh7_uda5是很重要的Type,我将会在后面对其进行深入介绍 。正如我们在上面说过的,动态编译是按需编译,现在我们对Default Page进行访问,由于这次对该Website的第一次访问,所有需要的Source Code,包括aspx,code behind都要进行编译 。在这个Sample中,虽然我们并没有访问Default2 page,但是我们说过,ASP.NET动态编译是基于目录的,由于Default Page和Default2 Page都直接置于根目录下,所以ASP.NET会把根目录下的所有文件编译到一个Assembly中 。由于Page1和Page2位于子目录Part I和Part II之下,所以不会参与编译 。除非我们下载对它进行Request 。 我们现在来访问Part I下的Page1和Page2看看会有什么结果 。我们会发现,两次Request获得的输出是一样的: 有了上面的理论和实验结果,我想这个时候,你肯定已经想到,如果我现在对Part II的Page1和Page2进行访问,输出结果会是什么样子了 。 |