什麼是通用語言運行時（CLR），簡單來講：

CLR是一個支持多種編程語言及多語言互操作，完整的高級虛擬機。

有點拗口，而且不是很有啟發性，但上面的文字是將又大又複雜的CLR的功能歸類以便容易理解的第一步。它從一萬英尺的高度來幫助我們理解CLR的設計目標。從這個高度明瞭CLR之後，我們可以深入其各個組件了。

CLR: 一個（極少見的）完整編程平臺

每個程式在運行的時候都有驚人數量的運行時依賴。雖然程式很明顯都是由一種特定的編程語言寫就，但這隻是程式員編寫程式多種依據中的一種。每個有用的程式都需要某些 運行時函數庫 以便其能跟電腦的其它資源（如用戶輸入設備，磁碟文件，網路通信等）交互。程式也需要轉換成電腦硬體可以直接執行的某種格式。這些依賴的數量是如此之多，範圍之廣，使得編程語言的設計者通常都引用其它標準來規範它們。例如C++編程語言不會規定C++程式的格式，每個C++編譯器都會與特定的硬體架構（如x86架構）關聯，與特定的操作系統環境（如Windows，Linux或者Mac OS）關聯，這些架構和環境會規定可執行文件的文件格式以及載入的方式。因此，程式員不是在編寫一個“C++可執行程式”，而是“Windows X86可執行程式”或“Power PC Mac OS可執行程式”。

復用現有的硬體或操作系統標準通常都是好事情，但其使得在現有標準之上抽象出新的規範變得很難。例如，今天的操作系統沒有支持垃圾回收的堆。因此也就無法使用現有的標準來支持垃圾回收的介面（如，將字元串傳來傳去，不需要關註刪除它們）。同樣，一個典型的可執行文件格式只提供足夠運行程式的信息，但不足夠編譯器將其他可執行文件綁定在一起運行。比如說，C++程式一般都使用包含經常使用功能（如printf）的標準庫（在Windows里是msvcrt.dll），但只有這個庫是不夠的。沒有對應的頭文件（如，stdio.h），程式員是無法使用這些函數庫的。因此，已有的可執行文件格式標準不能同時描述可執行的文件格式，並添加其它一些信息。

CLR通過定義一個 [非常完整的規範]ecma-spec來描述一個程式從編譯、到部署時綁定依賴、到運行整個生命周期的所有信息。因此，除去其他細節，CLR定義了

• 一套支持GC，並包含自己的執行程式基本操作的指令集（通用中間語言 - CLI）的虛擬機，這也就意味著CLR不需要依賴指定類型的CPU；
• 一套描述程式里聲明的元素（如類型、值、變數等等）的元數據，以便編譯器在生成其它可執行文件時有足夠的信息來從“外部”調用程式里的功能；
• 一個精確描述位元組應該如何在文件裡布局的文件格式，這樣我們在討論CLR EXE的時候，不與某個特定的操作系統或電腦硬體綁定；
• 進程的生命周期語義，即一個CLR EXE引用其它CLR EXE的機制，和CLR在運行時找到進程依賴文件的規則；
• 利用CLR內置功能（如垃圾回收、異常和泛型等）的類庫，其除了提供如整形、字元串、數組、列表和字典等基本功能意外，還提供瞭如文件、網路和UI交互等操作系統服務。

多編程語言支持

定義、規範和實現這些細節是一個艱巨的任務，這也就是類似CLR的完整抽象非常少的原因。實際上，大部分抽象都是為單個編程語言設計的。例如，Java運行時，Perl解釋器或者早期的Visual Basic運行時提供了類似的完整抽象。但CLR跟這些先行者不同之處在於其支持多種編程語言。可能除了Visual Basic（因為它採用了COM對象模型），僅使用單個編程語言的體驗是非常好的，但是要與其它編程語言互操作時體驗就有點差了。編程語言之間互操作之所以困難，是因為這些編程語言僅能通過操作系統提供的原語來與“外族”編程語言通信。而操作系統的抽象層次太低階（如操作系統不提供記憶體垃圾回收），就不得不採用一些複雜的技術。通過提供 通用語言運行時，CLR允許編程語言之間採用高階結構（如可GC的數據結構）通信，大量減輕了互操作的麻煩。

由於運行時在 許多 語言之間共用，這就意味著更多的資源可被支持。為一個編程語言實現好的調試器和性能分析工具需要大量的工作，因此只有一些很重要的編程語言才有完整的工具鏈支持。然而，CLR上實現的編程語言可以共用這些基礎架構，實現新的編程語言的工作量也大大縮減了。也許更重要的是，所有在CLR上實現的編程語言都可以訪問 所有 在CLR上實現的類庫。龐大且不斷增長的（嚴格調試和支持）功能是CLR如此成功的一個重要原因。

簡單來講，CLR是一個將位元組存到文件以創建和運行程式的完整規範。虛擬機可以使用不同編程語言寫就的類庫來運行這些程式。這個虛擬機，還有運行其上的不斷增長的類庫，就是我們說的通用語言運行時（CLR）。

來自文集：.NET框架源碼解析