『架構設計（第2版）CLR Via C#』學習筆記（001）——將原始碼編譯成託管模組

聲明：本文是讀書筆記，大部分內容是照書抄的，作為自己學習使用，(*^__^*) 嘻嘻……

以前在開發系統時，總是要決定使用什麼程式設計語言。這是一個很難的任務，因為不同的語言具有不同的能力。但是自從.net出現以後，問題得到瞭解決，讓我們先來看看下面這個圖吧

公用語言運行庫（Common Language Runtime，CLR）是一個可以由多種不同的程式設計語言使用的運行庫。CLR的特性可由面向它的所有語言來使用。事實上，在運行時，CLR根本不關心開發人員用哪一種語言來寫原始碼。也就是說，我們在挑選程式設計語言時，應該根據自己所要表達的意圖選擇最容易的程式設計語言。

實際上我們可以把編譯器當作一個語法檢查器和“正確代碼”分析器。Microsoft面向這個運行庫已經建立了幾種語言的編輯器，例如c++/CLI、C#、Visual Basic、JScript、J#以及一個“中繼語言”（Intermediate Language，IL）彙編器。除了Microsoft外，還有一些公司或學校或者愛好者建立了自己的編譯器，它們也能面向CLR產生代碼。

本地代碼編譯器產生的是一種特定的CPU構架專用的代碼。相反，所有CLR相容的編譯器產生的都是“中繼語言（Intermediate Language，IL）”代碼。IL代碼有事也被稱之為Managed 程式碼。

除了產生IL，面向CLR的每個編譯器還需要在每個託管模組中產生完整的中繼資料（metadata）。簡言之，中繼資料（metadata）是一系列特殊的資料表，它們描述了模組中定義的內容，比如類型及其成員，除此之外，還由一些中繼資料表指出了託管模組引用的內容，比如匯入的類型及其成員。雖然我們知道中繼資料是一些老技術的超集。這些老技術包括“類型庫（Type Library）”和“介面定義語言（Interface Definition Language，IDL）”檔案等。要注意的一個重點是，CLR的中繼資料比它們要完整的多。另外，和類型庫及IDL不同，中繼資料總是與包含IL代碼的檔案關聯在一起。事實上，中繼資料總是嵌入與代碼相同的EXE/DLL，這使兩者密不可分。由於編譯器同時產生中繼資料和代碼，並將它們綁定到最終產生的託管模組中，所以中繼資料及其描述的IL嗲嗎永遠不會失去同步。

那麼託管模組究竟包含些什麼那，讓我們來看看：

•  PE32或PE32+頭    標準Windows PE檔案頭，它類似於“公用對象檔案格式（Common Object File Format，COFF）”頭。 如果這個頭使用PE32格式，則檔案能在Windows的32位或64位版本上運行。如果這個標頭檔使用PE32+格式，則檔案只能在Windows64位版本上運行。這個頭還標示了檔案類型：GUI、CUI或者DLL，並包含一個時間戳記來指出檔案的產生時間。對於只包含IL代碼的模組，PE32(+)頭的大多資訊會被忽視。對於包含本地CPU代碼的模組，這個頭包含了與本地CPU代碼有關的資訊。
•  CLR頭    包含使這個模組成為一個託管模組的資訊（由CLR和公用程式來解釋）。頭中包含所要求的CLR版本，一些標誌，託管模組入口方法（Main方法）的MethodDef中繼資料標記，以及模組的中繼資料、資源、強式名稱、一些標誌及其他不太重要的資料項目的位置/大小。
•  中繼資料    每個託管模組都包含中繼資料表。主要由兩種類型的表：一種類型的表描述原始碼中定義的類型和成員，另一種類型的表描述原始碼中引用的類型和成員。
•  中繼語言（IL）代碼    編譯器編譯原始碼時產生的程式碼。在運行時，CLR將IL編譯成本地CPU指令。

下面讓我們來簡單的看一下中繼資料到底由什麼用途，這裡僅列出一部分。

• 在編譯時間，中繼資料消除了對頭和庫檔案的需求，因為與引用的類型/成員有關的所有資訊都包含在用IL來實作類別型/成員的檔案中。編譯器可以直接從託管模組讀取中繼資料。
• Microsoft Visual Studio使用中繼資料來協助我們寫代碼。它的“智能感知（IntelliSense）”特效能解析中繼資料，指出一個類型提供了什麼方法、屬性、事件和欄位。如果是一個方法，還能指出方法需要什麼參數。
• CLR的代碼驗證過程使用中繼資料來確保代碼只執行“安全”的操作。
• 中繼資料允許將一個對象的欄位序列化到一個記憶體中，將其發送給另一台機器，然後還原序列化，在遠程機器上重建對象狀態。
• 中繼資料允許垃圾收集器跟蹤對象的生存期。垃圾收集器能判斷任何對象的類型，並根據中繼資料知道那個對象中的哪些欄位引用了其他對象。