當前位置：首頁 > 编程语言 > asp.net >内容正文

asp.net

深入剖析ASP.NET的编译原理之一：动态编译（Dynamical Compilation）

發布時間：2025/5/22 asp.net 34 豆豆

生活随笔收集整理的這篇文章主要介紹了深入剖析ASP.NET的编译原理之一：动态编译（Dynamical Compilation）小編覺得挺不錯的,現在分享給大家,幫大家做個參考.

原文:http://www.cnblogs.com/artech/archive/2007/05/21/753620.html

Microsoft 的Visual Studio為我們在應用開發中提供的強大功能，我們是有目共睹。借助該工具，是我們的開發顯得更加高效而輕松。從Microsoft把這個IDE的名字從VS.NET 該為VS（比如原來的Visual Studio.NET 2003，現在的版本叫VS2005），可以MS對該IDE的期望和野心：MS要把它改造成一個萬能的IDE。不過任何都有其兩面性，對于我們廣大的開發者來說，VS是我們的各種行為簡單化，傻瓜化；但是在另一方面，他也會蒙蔽我們的眼睛，使我們對它背后做的事情視而不見。以我們的ASP.NET Website開發為例，編程、編譯、部署都可以借助VS，有了VS一切顯得如此簡單，每個人都會做，但是我想很多一部分人對一個ASP.NET Website如何進行編譯不會很了解。這篇文章就來談談背后的故事——ASP.NET是如何進行編譯的。由于篇幅的問題整篇文章分兩個部分：動態編譯Dynamical Compilation和預編譯（Precompilation）。

1．動態編譯的過程

我們先來介紹在動態編譯下的大體的執行流程：當ASP.NET收到一個基于某個page的request的時候，先判斷該Page和相關的Source code是否編譯過，如果沒有就將其編譯，如果已經編譯，就是用已經Load的Assembly直接生成Page對象。

在這里有下面幾點需要注意：

1)．動態編譯是按需編譯的，ASP.NET只會編譯和當前Request相關的aspx和code。

2)．動態編譯是基于某個目錄的，也就是說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中設置你需要的臨時目錄。

<compilation?tempDirectory="d:\MyTempFiles"?/>

2．Sample

現在我用一個Sample來一探ASP.NET是如何進行動態編譯的。

在這個Sample中，我建立了一個Website，在根目錄下創建了兩個Page：Default和Default2。

在兩個子目錄Part I和Part II下分別創建了兩個Web page:Page1和Page2。在App_Code目錄中創建了一個Utility的static class。下面是它的定義：

public?static?class?Utility
{
????public?static?string?ReflectAllAssmebly()
????{
????????StringBuilder?refllectionResult?=?new?StringBuilder();

????????foreach?(Assembly?assembly?in?AppDomain.CurrentDomain.GetAssemblies())
????????{
????????????if(!assembly.FullName.Contains("App_Web"))
????????????{
????????????????continue;
????????????}

????????????refllectionResult.Append(assembly.FullName?+?"<br/>");
????????????Type[]?allType?=?assembly.GetTypes();
????????????foreach?(Type?typeInfo?in?allType)
????????????{
????????????????refllectionResult.Append("     "+?typeInfo.Name?+?"<br/>");
????????????}
????????}

????????return?refllectionResult.ToString();
????}
}

內容很簡單，對當前加載的所有相關的Assembly（這些Assembly的Fullname以App_Web打頭）進行Reflection，列出所有的Type。這個ReflectAllAssmebly將在5個Web page（Default?Page和兩隊Page1&Page2）的Page_Load事件中被調用。

protected?void?Page_Load(object?sender,?EventArgs?e)
????{
????????this.Response.Write(Utility.ReflectAllAssmebly());
}

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，但是我們說過，動態編譯是基于目錄的，由于Default Page和Default2 Page都直接置于根目錄下，所以ASP.NET會把根目錄下的所有文件編譯到一個Assembly中。由于Page1和Page2位于子目錄Part I和Part II之下，所以不會參與編譯。除非我們下載對它進行Request。

我們現在來訪問Part I下的Page1和Page2看看會有什么結果。我們會發現，兩次Request獲得的輸出是一樣的：
通過上面的輸出我們發現，當前AppDomain中被加載的Assembly多了一個：App_Web_n1mhegpg。我們可以通過定義在該Assembly中的Type的命名可以猜出該Assembly是對Part I 目錄進行編譯產生的。Page1和Page2的編譯后的Type name變成了part_i_page1_aspx& Page1和part_i_page2_aspx& Page2。此外我們看到，該Assembly中依然有一個FastObjectFactory的Type：FastObjectFactory_app_web_n1mhegpg。在這里我需要特別指出的是，名稱的后綴都是通過 Hash算法得到的。

有了上面的理論和實驗結果，我想這個時候，你肯定已經想到，如果我現在對Part II的Page1和Page2進行訪問，輸出結果會是什么樣子了。
如果這個時候，你查看臨時目錄（Directory\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files）中該Website對應的子目錄，已將會看到生成了一些列的文件。

3．Page最終被轉化成什么？

我們現在來看看通過編譯，一個Page到底轉換成什么。我們以Part I/Page1為例。通過上面的Sampe，我們知道它最終變成了兩個Type：Page1和part_i_page1_aspx。

下面是Page1的定義：

public?class?Page1?:?Page,?IRequiresSessionState
{
????//?Fields
????protected?HtmlForm?form1;

????//?Methods
????protected?void?Page_Load(object?sender,?EventArgs?e)
????{
????????base.Response.Write(Utility.ReflectAllAssmebly());
????}

????//?Properties
????protected?HttpApplication?ApplicationInstance
????{
????????get
????????{
????????????return?this.Context.ApplicationInstance;
????????}
????}

????protected?DefaultProfile?Profile
????{
????????get
????????{
????????????return?(DefaultProfile)?this.Context.Profile;
????????}
????}
}
下面是part_i_page1_aspx的定義

[CompilerGlobalScope]
public?class?part_i_page1_aspx?:?Page1,?IHttpHandler
{
????//?Fields
????private?static?object?__fileDependencies;
????private?static?bool?__initialized;

????//?Methods
????public?part_i_page1_aspx();
????private?HtmlHead?__BuildControl__control2();
????private?HtmlTitle?__BuildControl__control3();
????private?HtmlLink?__BuildControl__control4();
????private?HtmlForm?__BuildControlform1();
????private?void?__BuildControlTree(part_i_page1_aspx?__ctrl);
????protected?override?void?FrameworkInitialize();
????public?override?int?GetTypeHashCode();
????public?override?void?ProcessRequest(HttpContext?context);
}

在part_i_page1_aspx中定義了一個基于aspx的HttpHandler所需的所有操作，并且它繼承了Page1。所以我們可以說Part I/Page1這個page 最終的體現為part_i_page1_aspx。進一步說，對Part I/Page1的Http Request，ASP.NET所要做的就是生成一個part_i_page1_aspx來Handle這個request就可以了。?

4．FastObjectFactory

通過上面的一個簡單的Sample，你已經看到每個Assembly中都會生成一個以FastObjectFactory作為前綴的Type。這是一個很重要的Type，從它的名稱我們不難猜出它的作用：高效的生成對象。而生成的是什么樣的對象呢？實際上就是基于每個aspx的Http request的Http handler，對于Part I/Page1就是我們上面一節分析的part_i_page1_aspx對象。

我們現在通過Reflector查看我們生成的App_Web_n1mhegpg中的FastObjectFactory_app_web_n1mhegpg是如何定義的。

internal?class?FastObjectFactory_app_web_n1mhegpg
{
????//?Methods
????private?FastObjectFactory_app_web_n1mhegpg()
????{
????}

????private?static?object?Create_ASP_part_i_page1_aspx()
????{
????????return?new?part_i_page1_aspx();
????}

????private?static?object?Create_ASP_part_i_page2_aspx()
????{
????????return?new?part_i_page2_aspx();
????}
}

通過上面的Code，我們可以看到在FastObjectFactory中定義一系列的Create_ASP_XXX(后綴就是Page 編譯生成的Type的名稱)。通過這些方法，可以快速生成對一個的Page。至于為什么會叫作FastObjectFactory，我想是因為直接通過調用這個靜態的方法快速地創建Page對象，從而避免使用Reflection的late binding帶來的性能的影響吧。

5．Preservation Files

進行每一次編譯，ASP.NET會生成一系列具有.compiled擴展名的保留文件（Preservation File）。這個文件非常重要，我們現在來深入介紹這個樣一個文件。

Preservation File這個文件本質上是一個XML。它是基于每個Page的，也就是每個Page都會有一個這樣的Preservation File. 無論Page對應的Directory是怎樣的，與之對應的Preservation File總會保存在根目錄下，所以必須有一種機制保持為處于不同Directory的Page生成的Preservation File具有不同的文件名，不管Page的名稱是否一樣。所以Preservation File采用下面的命名機制：

[page].aspx.[folder-hash].compiled

其中[page]是Page的名稱，[folder-hash]是對page所在路徑的Hash Value。這樣做有兩個好處。

保證處于同一級目錄的所有Preservation File具有不同的文件名。
保證ASP.NET對于一個Http request可以找到Page對應的Preservation File。

下面這個Preservation File就是上面Sample中Part II/Page1.aspx對應的Preservation File，名稱為default2.aspx.cdcab7d2.compiled。我們來看看XML每個Item各代表什么意思。

<?xml?version="1.0"?encoding="utf-8"?>
<preserve?resultType="3"?virtualPath="/Artech.ASPNETDeployment/Part?II/Page1.aspx"?hash="fffffff75090c769"?filehash="5f27fa390c45c52a"?flags="110000"?assembly="App_Web_hitlo3dt"?type="ASP.part_ii_page1_aspx">
????<filedeps>
????????<filedep?name="/Artech.ASPNETDeployment/Part?II/Page1.aspx"?/>
????????<filedep?name="/Artech.ASPNETDeployment/Part?II/Page1.aspx.cs"?/>
????</filedeps>
</preserve>

有這段XML我們可以看到，所有的內容都包含在preserve XML element中，在他中間定義了幾個重要的attribute.

virtualPath: Page的虛擬地址。
assembly：Assembly名稱
Type：Page的編譯后對應的Type（Http handler）。
hash: 一個代表本Preservation File狀態的Hash value。
filehash: 一個代表本Dependent File狀態的Hash value。

通過hash和filehash的緩存，ASP.NET可以判斷自上一次使用以來，Preservation File和它所依賴的Dependent File是否被改動，如果真的被改動，將會重新編譯。因為對于文件的任何改動都會導致該Hash value的改變。

此外，Preservation File的<filedeps>列出了所有依賴的文件，對于Page,一般是aspx和code behind。

6. 進一步剖析整個動態編譯過程

現在我們來總結整個動態編譯的過程：

Step1：當ASP.NET收到對于某個Page的Request，根據這個request對應的Url試著找到該page對應的Preservation File，如果沒有找到，重新編譯Page所在目錄下的所有需要編譯的文件，同時生成一些額外的文件，包括Preservation File。

Step2：然后解析這個Preservation File，通過hash和filehash判斷文件自身或者是Dependent File是否在上一次編譯之后進行過任何的修改，如果是的，則重新編譯。然后重新執行Step2。

Step3：通過Preservation File 的assembly attribute Load對應的assembly(如果Assembly還沒有被Load的話)，通過type獲知對應的aspx type，然后借助FastObjectFactory的對應的Create_ASP_XXX創建這個type。這個新創建的對象就是我們需要的Http Handler，在之上執行相應的操作把結果Response到客戶端。

對動態編譯的討論就到這里，在本篇文章下半部分將會討論另一種更加有用的編譯方式：[原創] 深入剖析ASP.NET的編譯原理之二：預編譯（Precompilation）。

轉載于:https://www.cnblogs.com/answercard/archive/2009/01/08/1371599.html

《新程序員》：云原生和全面數字化實踐50位技術專家共同創作，文字、視頻、音頻交互閱讀

總結

以上是生活随笔為你收集整理的深入剖析ASP.NET的编译原理之一：动态编译（Dynamical Compilation）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。

上一篇： VSTS问题二则
下一篇：使用jQuery for Asp.Net