CLR 這些年有啥變化嗎？

引言

　　首先想給初學者推薦下《CLR via C#》這本好書，作.Net開發的開發者應該都讀一下。爲避免廣告之嫌，因此這裏只提供豆瓣書評的連接。

　　CLR 做爲.Net 程序跨平臺運行的載體，和Java的JVM有着相似的功能（JAVA爲跨平臺而生，實現這一目標離不開JVM）。

　　隨着.NET Framework的日益發展CLR也有突飛猛進的變化。這些變化爲開發帶來更多有用的特性，在提升開發效率的同時也提升了程序的性能和穩定性。

　CLR是什麼

通用語言運行時(CommonLanguageRuntiome,CLR)最先被稱爲下一代Windows服務運行時(NGWS Runtime).它是直接創建在操做系統上的一個虛擬環境，主要的任務是管理代碼的運行。

　CLR在.NetFramework中的位置

.NET平臺結構圖

　　CLR如今支持幾十種現代的編程語言爲它編寫代碼，而後以一種中間語言(Intermediate Langeoage,IL)代碼的造成被執行。而且，CLR還提供了許多功能以簡化代碼的開發和應用配置，同時也改善了應用程序的可靠性。如你所知，若是某種語言的編譯器是以運行時爲目標的，那麼利用該語言開發生成的代碼在.NET中被稱爲託管代碼（MSIL），由於這樣的代碼是直接運行在CLR上的，因此具備與平臺無關的特色。

　　目前有哪些語言支持CLR

微軟已經爲多種語言開發了基於CLR的編譯器，這些語言包括：C++/CLI、C#、Visual Basic、F#、Iron Python、 Iron Ruby和IL。

除此以外，其餘的一些公司和大學等機構也位一些語言開發了基於CLR的編譯器，例如Ada、APL、Caml、COBOL、Eiffel、Forth、Fortran、Haskell、Lexicon、LISP、LOGO、Lua、Mercury、ML、Mondrian、Oberon、Pascal、Perl、PHP、Prolog、RPG、Scheme、Smaltak、Tcl/Tk。

　　在.NET平臺結構圖中，CLR的上面是.NET的基類庫，這組基類庫包括從基本輸入輸出到數據訪問等各方面，提供了一個統一的面向對象的，層次化的，可擴展的編程接口。從.NET平臺結構圖中也能夠看到，基類庫能夠被各類語言調用和擴展,也就是說不論是 C#，VB.NET仍是F#,VC++.NET,均可以自由的調用.NET的類庫。

　CLR內部結構

　　從上圖能夠看到CLR提供的功能，如類型安全(Type Checker)、垃圾回收（Garbage Collector）、異常處理(Exception Manager)、向下兼容(COM Marshaler)等，具體的說，.NET上的CLR爲開發者提供以下的服務：

• 平臺無關：CLR其實是提供了一項使用了虛擬機技術的產品，他在操做系統之上，並不要求程序的運行平臺是 Windows系統，只要是可以支持它的運行庫的系統，均可以在上面運行.NET應用。因此，一個徹底由託管代碼組成的應用程序，只要編譯一次，就能夠在任何支持.NET的平臺上運行.（從Mono的出現變得更加真實啦,不用再羨慕JAVA啦）
• 跨語言集成：CLR語序開發這以任何語言進行開發，用這些語言開發的代碼，能夠在CLR環境下緊密無縫的進行交叉調用，例如，能夠用VB聲明一個基類對象，而後在C#代碼中直接建立次基類的派生類。
• 自動內存管理：CLR提供了拉架收集機制，能夠自動管理內存。當對象或變量的生命週期結速後，CLR會自動釋放他們所佔用的內存.
• 跨語言異常處理
• 版本控制（避免了DLL災難）
• .NET安全
• 簡單的組件互操做性。
• 自描述組件：自描述組件是指將全部數據和代碼都放在一個文件中的執行文件。自描述組件能夠大大簡化系統的開發和配置，而且改進系統的可靠性。

　CLR 執行示意圖

　　CLR 在整個.Net Framework 程序執行過程的模型，C#、VB.Net,C++.Net 代碼經過編譯器生成了MSIL（託管代碼），而後CLR用JIT翻譯成native code ，最後就能夠直接執行啦。

　CLR 版本發展史

　　C#版本 和.Net Framework 版本以及CLR依賴關係 和新特性添加列表,

The .NET Framework 4.5 is an in-place update that replaces the .NET Framework 4 on your computer, and similiarly, the .NET Framework 4.5.1 4.5.2, and 4.6 RC are in-place updates to the .NET Framework 4.5, which means that they use the same runtime version, but the assembly versions are updated and include new types and members. After you install one of these updates, your .NET Framework 4 or .NET Framework 4.5 apps should continue to run without requiring recompilation. However, the reverse is not true. We do not recommend running apps that target a later version of the .NET Framework on the .NET Framework 4.5.

　　上面的整體意思就是:

• .NET Framework 4.5 是.NetFramework 4.0的代替者
• .NET Framework 4.5.1 4.5.2, and 4.6 RC 是.NetFramework 4.5的代替者

　　從.net 4 開始，若是您想把.NetFramework 4.0+ 到更新的更新版本的.NetFramework,只需從新指定目標.Net Framwork而後從新編譯代碼便可，反之不可行。

　　之因此能夠這樣作是由於這幾個.NetFramework版本的CLR都是4.0版本的。

The .NET Framework versions 2.0, 3.0, and 3.5 are built with the same version of the CLR (CLR 2.0). These versions represent successive layers of a single installation. Each version is built incrementally on top of the earlier versions. It is not possible to run versions 2.0, 3.0, and 3.5 side by side on a computer. When you install version 3.5, you get the 2.0 and 3.0 layers automatically, and apps that were built for versions 2.0, 3.0, and 3.5 can all run on version 3.5. However, the .NET Framework 4 ends this layering approach. Starting with the .NET Framework 4, you can use in-process side-by-side hosting to run multiple versions of the CLR in a single process. For more information, see Assemblies and Side-by-Side Execution.

In addition, if your app targets version 2.0, 3.0, or 3.5, your users may be required to enable the .NET Framework 3.5 on a Windows 8 or Windows 8.1 computer before they can run your app. For more information, see Installing the .NET Framework 3.5 on Windows 8 or 8.1

　　這段話的意思是

• .NET Framework versions 2.0, 3.0, and 3.5 每一個版本都是在前一個版本基礎上增量開發的
• .NET Framework versions 2.0, 3.0, and 3.5 不一樣版本的程序不能在同一機器上同時運行在不一樣CLR上。（在安裝 3.5 版後，你將無需安裝 2.0 和 3.0 版本，2.0、3.0 和 3.5 生成的應用程序都可在 3.5 版上運行）
• 從 .NET Framework 4 開始，在單個進程中可以使用進程內並行運行在多個版本的CLR 。（即4.0的dll引用了2.0的dll是，4.0的代碼在CLR4.0上運行而2.0的代碼運行在CLR2.0上）
• 此外，若是你的應用程序使用的是 2.0、3.0 或 3.5 版，你的用戶可能須要先在（Windows7） Windows 8 或 Windows 8.1計算機上啓用 .NET Framework 3.5，而後才能運行應用程序。

　　順便看下 各個.Net Framework 新功能：

　CLR最新發展

　　將來.NEtFrameWork 會有新的兄弟進來一塊兒構建.Net 跨平臺和雲架構的夢想。

　　上圖中Core CLR是Asp .Net vNext很重要的核心之一，雖然官方沒說，但基本上就是一個精簡版的CLR，拿掉了繪圖等功能，讓Server和Cloud程序更高效

　　至於MonoCLR,你們看名字就知道是爲了更好的支持Mono這個開源的新秀的。

　　Update1：摘自MSDN的《使用 CoreCLR 編寫 Silverlight》

自 2005 年 10 月發行 CLR 的 2.0 版本後就開始了 CoreCLR 的設計。它的兩個主要設計目標是大小和兼容性：從編程人員的角度來看，針對 CLR 的編碼應該始終相同，而從用戶的角度來看，下載必須很是小。因爲 Silverlight 旨在提供一組不一樣於桌面 CLR 的方案，所以，咱們能夠進行一些更改，以簡化 CoreCLR 並容許咱們縮減 Silverlight 的安裝大小。可是，堆棧底部的一致性相當重要。行爲差別（即便這些行爲差別都正確）代表堆棧上部有錯誤。

爲了確保兼容性，咱們在堆棧底部的各個組件中使用相同的代碼。執行引擎和虛擬機都是相同的。其中包括類型系統和元數據、垃圾回收器 (GC)、JIT 編譯器、線程池以及運行時引擎的其餘核心部件。

可是，爲了適應 Web 應用程序方案，進行了一些更改。例如，富 Internet 應用程序一般簡單且運行時間短，JIT 編譯器主要側重於減小啓動時間，而非執行更復雜的優化操做。一樣，服務器垃圾回收模式能夠對使用類似分配模式的多個工做線程進行優化，而對 Web 託管應用程序則行不通。所以，Silverlight 只包含針對交互式應用程序進行優化的標準工做站 GC。可是，在 Silverlight 應用程序中使用 Microsoft 中間語言 (MSIL) 和元數據的方式與在針對桌面的託管應用程序中的使用方式徹底相同，並且應用程序的行爲在用戶的桌面上和在瀏覽器上一致。

事實上，Silverlight 並不打算取代桌面 CLR，這就引起了核心引擎中最大的變化：CoreCLR 將與桌面 CLR 進程並行運行。