.NET架構筆記-CLR

　　.NET架構的核心便是通用語言運作時(Common Language Runtime,簡稱CLR)可被各種不同的程式設計語言所使用的運作時。CLR的很多特性可用于所有面向它的程式設計語言。比如,如果CLR用異常來報告錯誤，那麼所有面向他的語言都将通過異常來得到錯誤報告,如果CLR容許我們建立線程,那麼所有面向它的語言都可以建立線程。

　　實際上，CLR在運作時對開發人員用何種程式設計語言來完成源代碼一無所知。這意味着我們應該選擇那些能夠容易表達我們意圖的程式設計語言。我們可以用任何自己喜歡的語言來編寫代碼，前提是我們使用的編譯器能夠編譯面向CLR的代碼。

　　上圖示範了源代碼檔案的編譯過程。如圖所示，我們可以用任何支援CLR的程式設計語言來建立源代碼檔案。然後用相應的編譯器來做文法檢查和源代碼分析。但是不管使用的是何種編譯器，最後生成的結果都是一個托管子產品（managed module）。托管子產品是一個需要CLR才能執行的标準Windows可移植可執行（portable executable,簡稱PE）檔案。随着時間的推移，其他一些作業系統也有可能采用這種PE檔案格式。

　　　　　　　　　　　　　　　　　　　　　　　　　　　　托管代碼組成部分

　　PE表頭：标準Windows PE檔案表頭，類似于通用檔案格式表頭。該表頭指出了檔案的類型：GUI(圖形使用者界面),CUI(控制台使用者界面)，或者DLL。另外該表頭還包括一個時間标記永遠辨別檔案建立的時間。對于僅包含IL代碼的子產品，該表頭的大多數資訊會被忽略。對于包含有本地CPU代碼的子產品，該表頭還會包含有關本地CPU代碼的一些資訊。

　　CLR表頭：包含辨別托管的一些資訊。這些資訊包括托管子產品所需要的CLR版本号，一些标記，托管子產品入口點方法的MethodDef中繼資料标記，以及有關托管子產品的中繼資料、資源、強命名、标記和其他一些意義不是太大的資訊的位置和尺寸。

　　中繼資料：每個托管子產品都包含有一些中繼資料表。中繼資料表主要分兩種，一種用于描述源代碼中定義的類型和成員，一種用于描述源代碼中引用的類型和成員

　　中間語言IL代碼：編譯器在編譯源代碼時産生的指令。CLR在運作時會将IL代碼編譯成本地CPU指令。由于生成期和執行行為受CLR管理的緣故，IL代碼有時也被稱作托管代碼

　　除了産生IL外，所有面向CLR的編譯器都需要為托管子產品産生完整的中繼資料，簡單的說中繼資料就是一個資料表的集合，在這些表中，其中一些用于描述托管子產品中所定義的内容。中繼資料是一些早先的技術如類型庫、接口定義語言（IDL）檔案的一個超集。需要指出的是CLR的中繼資料遠比他們完整。而且不像類型庫和IDL，中繼資料總是和包含IL代碼的檔案相關聯。實際上，中繼資料總是和這些代碼一起被嵌入到同一個EXE/DLL檔案中，兩者根本不可能分離。因為編譯器總是同時産生中繼資料和IL代碼，并且總是同僚将他們嵌入到生成的托管子產品中，是以中繼資料和他所描述的IL代碼之間總能保持同步。

　　中繼資料有很多用處。下面列出了其中的一些：

　　*　　中繼資料省去了源代碼編譯時對頭檔案和庫檔案的需求，這是因為在含有現實類型和成員的IL代碼檔案中，已經包含了所有被引用的類型和成員的資訊。編譯器可以直接從托管子產品中讀取中繼資料來獲得這些資訊

　　*　　Visual Studio .NET可以利用中繼資料來輔助我們編寫代碼。它的智能感覺特性就是通過分析中繼資料來告訴我們某個類型提供了哪些方法，以及某個方法有哪些參數。

　　*　　CLR的代碼驗證過程可以利用中繼資料來確定代碼僅執行安全操作

　　*　　利用中繼資料，我們可以将一個對象的字段序列化到一個記憶體快中，然後遠端傳遞給另一台機器，最後在遠端機器上執行反序列化

　　*　　利用中繼資料，垃圾回收機制可以追中對象的生存期。對于任何對象，垃圾回收器都能夠通過中繼資料來确定該對象的類型，并且可以獲知該對象的哪些字段引用了其他對象

　　

轉載于:https://www.cnblogs.com/xiany/archive/2012/09/20/2696198.html