魅力 .NET：從 Mono、.NET Core[轉]

前段時間，被問了這樣一個問題：.NET 應用程序是怎麼運行的？

當時大概愣了很久，好像也沒說出個因此然，獲得的回覆是：這是 .NET 程序員最基本的。。。呵呵！

微軟開源，其實不僅是對 .NET 自己有利，從另外一方面講，對於 .NET 程序員來講，由於開源，你能夠想了解到你想要的任何事。在以前的歲月，你能夠「平凡」作一個默默無聞的 C# 代碼撰寫者，能夠不用考慮任何事，使用宇宙最強大的 IDE - Visual Studio 編寫代碼後，發佈到 IIS 便可，就是這麼簡單，甚至你不須要知道 IIS 是怎麼運行的，代碼是怎麼託管的等等，你只須要寫好你的 C# 代碼便可，由於其他的一切工做，微軟已經幫你考慮並完成了。這樣雖然簡單而且高效，但對於 .NET 程序員來講，這就像「井底之蛙」同樣，你看不到外面的世界，你也沒有任何動力去跳出這個「深井」，而只是「溫馨」的觀望着外面你所認爲的「狹隘世界」。但 由於開源、跨平臺，這些平靜的日子都將被打破了，微軟開源出來的一個個項目、發表的一篇篇文章，怎麼愈來愈看不懂了？最後才發現，如今的微軟已經不是原來 咱們熟悉的那個微軟了，.NET 亦是如此。

我大概花了幾天的時間，去真正閱讀 .NET 開源的一些文章，雖然英文很爛，但我都堅持讀了下來，閱讀過程當中，愈來愈被 .NET 的魅力所吸引，並時不時的被一些「特殊表達「所逗笑，但這都只是在閱讀的過程當中，讀完、思考完，回到上面的那個問題，我仍是不能很好的去表述、回答它，這 時候我就意識到：腦子很差使，須要博客記錄，這篇博文能夠當作一篇閱讀筆記來看（再一次的閱讀）。

在好久好久以前，若是提到 .NET 跨平臺，你首先想到的應該是 Mono，那 Mono 究竟是什麼？它爲何能夠跨平臺？在 .NET 開源以前，我對這些是一無所知，理解微軟此次 .NET 跨平臺，須要首先了解 Mono，瞭解 Mono，首先你須要仔細閱讀下這篇文章：http://www.wikipedia.org/wiki/Mono。

摘錄

Mono 是一個由 Xamarin 公司（先前是 Novell，最先爲 Ximian）所主持的自由開放源代碼項目。該項目的目標是建立一系列符合 ECMA 標準（Ecma-334 和 Ecma-335）的 .NET 工具，包括 C# 編譯器和通用語言架構。 與微軟的 .NET Framework（共通語言運行平臺）不一樣，Mono 項目不只能夠運行於 Windows 系統上，還能夠運行於 Linux，FreeBSD，Unix，OS X 和 Solaris，甚至一些遊戲平臺，例如：Playstation 3，Wii 或 XBox 360。

重要的兩點：

• C# 編譯器：Mono 的 C# 編譯器及其相關工具發佈於 GNU 通用公共許可證（GPL）之下，其運行時庫發佈於 GNU 寬通用公共許可證（LGPL）之下，其類庫發佈於 MIT 許可證之下。這些均是開源協議，所以 Mono 是一個開源軟件。

• 通用語言架構：微軟開發了一個稱爲通用語言架構（Shared Source Common Language Infrastructure，Shared Source CLI；即今 ECMA—通用語言架構）的可用於 FreeBSD，Windows 和 Mac OS X 的 .NET 實現版本。微軟的共享源代碼協議並非開源軟件協議，且可能對於社區來講也是不足夠的（它明文禁止了對軟件的商業用途）。

再來看兩個概念：

• 公共語言基礎（Common Language Infrastructure，CLI）是一套標準（ECMA335），公共語言運行時（Common Language Runtime）即 CLR 是 CLI 標準的實現，Mono 是實現者之一。該運行時用於執行已編譯的 .NET 應用程序。公共語言基礎已被 ECMA 定義爲標準 ECMA-335。要運行一個 .NET 應用程序，你必須使用相應的參數調用運行時。通用語言基礎架構定義了構成 .NET Framework 基礎結構的可執行碼以及代碼的運行時環境的規範，它定義了一個語言無關的跨體系結構的運行環境，這使得開發者能夠用規範內定義的各類高級語言來開發軟件， 而且無需修正便可將軟件運行在不一樣的計算機體系結構上。

• 公共語言規範（Common Language Specification，CLS）定義了提供給公共語言基礎的接口，例如對於枚舉類型的隱含表示類型的協定。Mono 的編譯器負責生成符合公共語言規範的映射代碼，即公共中間語言（Common Intermediate Language，CIL）。Mono 的運行時將運行這類代碼。ECMA 標準先前還定義了一個符合公共語言規範的程序庫做爲應用框架。

理解

對於上面一大堆的協議或概念，理解起來是須要花點時間，首先 Mono 的各個部分都是基於各類開源協議，也就是說它是一個不折不扣的開源項目，再來大體理一下協議及其實現：

• GPL、LGPL 協議： C# 編譯器及其相關工具實現。

• CLI（公共語言基礎）：MS CLR、Mono（CLR 虛擬機），CLR 全稱爲 Common Language Runtime（通用語言運行時），須要注意的是，CLR 和 .NET Framework（.NET 框架）徹底不是一個概念，.NET Framework 是以一種採用系統虛擬機運行的編程平臺，以 CLR 爲基礎，支持多種語言（C#、VB.NET、C++、Python等）的開發庫。

• CLS（公共語言規範）：MSIL（微軟中間語言），現已更改成 CIL，也就是經過編譯器生成的中間語言。

能夠用來回答博文一開始那個問題的一張圖：

開發人員使用高級編程語言撰寫程序，接下來編譯器將代碼編譯成微軟的中間語言（MSIL），運行的時候 CLR 會將 MSIL 代碼轉換爲操做系統的原生代碼（Native code），CLR 內置有實時編譯器（中間代碼轉化爲原生代碼的編譯器）。

是否是仍是有點暈？其實說簡單也簡單，拋開應用程序和編譯器，.NET 的運行機制組成，其實就只有 CIL 和 CLR，CIL 是編譯器生成的中間語言，CLR 的做用就是將它再編譯成原始機器代碼。你可能還有一個疑問，咱們常說的 .NET Framework 究竟是什麼？它在 .NET 運行機制中到底扮演什麼角色？在上面演示圖中，其實 Source Code 並不包含 .NET Framework，Source Code 指的是你應用程序的源代碼，在上面有提到，.NET Framework 是以 CLR 爲基礎的開發庫，你能夠把它看做是編譯好的 CIL，它並無經過編譯器的再次編譯過程，而是直接經過 CLR 中的編譯器編譯爲原始機器代碼。

簡要總結：

• CLI -> CLR

• CLS -> CIL

• CLR 運行 CIL

好了，咱們再猜測一下，若是把 .NET 運行機制的各個組件進行分開重組，除去 .NET Framework 是微軟提供的，其他的組件，好比 C# 編譯器、CIL、CLR 等，都是 Mono 基於各類協議進行實現的組件，那若是你的應用程序代碼引用了 .NET Framework（微軟實現），很顯然，這個應用程序是沒法運行的，由於實現的 CLR 並非微軟的 CLR，因此針對 .NET Framework 來講，由於它的不開源，因此 Mono 須要另行實現基於本身 CLR 的基礎類庫，但這是一個龐大而複雜的工程，因此如今的 Mono 基礎類庫並非很完整，不少東西和微軟的 .NET Framework 並不能很好的兼容，因此你若是使用 Visual Studio 開發的項目，想遷移到 Mono Develop 下，是很是複雜的，固然，若是你沒有使用任何的 .NET Framework，是很是簡單的，但現實是，敲個最簡單的「Hello World」輸出代碼，都得引用 mscorlib.dll 程序集（System.Console）。

上面描述那麼多，我想表達什麼呢？其實咱們如今在 Windows 平臺下開發的 .NET 應用程序，是深深依賴於 .NET Framework（深深的那種），你的應用程序代碼基本上都是在它之上完成的，而 .NET Framework 又是深深依賴於 Windows 平臺下的 CLR（也是深深的那種），在這種狀況下，根本就沒法使你的應用程序跨平臺，由於微軟牢牢的抱住 Windows 平臺，妄想 Windows 能夠實現「大一統」，但現實是很殘酷的，此次的 .NET 開源、跨平臺，其實也是微軟的無奈之舉。但就是在這種背景下，Mono 出現了，而且在微軟的各類「排擠」下堅持了下來，這是很是不容易的，其實實現 .NET 跨平臺的三個關鍵是：編譯器、CLR 和基礎類庫，而 Mono 實質上就是把他們三個進行跨平臺實現了，一個很小團隊完成了一個巨頭須要完成的工做，並且仍是在這個巨頭的「排擠」下，其實這就是開源和社區的力量。

Mono 就說到這，有些疑問先放下，後面再進行講解，下面咱們來講一下 .NET Core 的相關內容。

須要認真閱讀的一篇文章：.NET Core is Open Source

這是 .NET 開源的一篇官方說明文章，內容不少（包括評論），若是你真正花時間去讀的話，這篇文章的信息量是很是大的，下面是我搜刮的一些片斷。

.NET Core 開源地址：https://github.com/dotnet/corefx。

.NET Core 包含：

• .NET Runtime（暫無）

• .NET Core Framework

編譯器、ASP.NET：

• C# & Visual Basic ("Roslyn")

• Visual F# Tools（暫無）

• ASP.NET 5

• Entity Framework

1. What is .NET Core?

答：.NET Core is a modular development stack that is the foundation of all future .NET platforms It’s already used by ASP.NET 5 and .NET Native.

關鍵詞：Modular（模塊化），如今的 .NET Core 只是增長了 .NET Core Framework 的一些代碼，.NET Runtime 並未添加任何代碼，這個須要時間，既然代碼都未添加完善，那爲何 ASP.NET 5 and .NET Native 如今能夠跨平臺了？由於他們沒有使用 .NET Core，而是使用獨立的 Runtime－KRuntime，如今已改名爲 XRE。

2. Why do we open source .NET Core?

比較「官方」的回答：

1. Lay the foundation for a cross platform .NET.

2. Build and leverage a stronger ecosystem.

其實翻譯過來就是「形勢所逼」，但事實真是如此嗎？其實也不盡然，看這一段敘述就明白一些了：

The challenge is that the Windows implementation has one code base while Mono has a completely separate code base. The Mono community was essentially forced to re-implement .NET because no open source implementation was available. Sure, the source code was available since Rotor but we didn’t use an OSI approved open source license, which made Rotor a non-starter. Customers have reported various mismatches, which are hard to fix because neither side can look at the code of the other side. This also results in a lot of duplicated work in areas that aren’t actually platform specific. A recent example is immutable collections.

這段敘述是頗有意思的，由於 .NET 的不開源，Mono 社區重寫了跨平臺的 .NET，又由於 Rotor 沒有基於任何 OSI 開源協議實現，因此致使 Mono 的實現充滿了困難，這些都是微軟親自認可的，想一想在之前，微軟會說這些嗎？相反它會高傲的擡起它的頭，其實從這一方面就能夠看出，Mono 社區這麼多年是多麼的不容易，微軟此次的改變也是多麼的不容易。爲了加深你的印象，微軟列舉了一個最新例子：immutable collections，Mono 團隊是這樣寫的說明：Unfortunately Microsoft didn't release their implementation under a license useable in mono I needed to reimplement the interfaces.，其實你能夠看出一種無奈，Immutable Collections 是 .NET Framework 的基礎核心類庫之一，這仍是之一，固然還有不少的實現，試想一下，若是 .NET 早就開放 .NET Framework 的源代碼，即便微軟沒有對它進行跨平臺，也會減小 Mono 團隊的開發難度，以及儘可能減小與 Windows 平臺實現應用程序的兼容問題，固然這都是後話。

Build and leverage a stronger ecosystem.

關於這部份內容的解讀，微軟主要說了兩點：Nuget 和 Interact，關於 Nuget，dudu 以前好像吐槽了好屢次，可是微軟說了，咱們花了兩年的時間去作這個東西，並獲得了很好的反饋，但好像獲得的反饋沒有來自國內，使用 Nuget 的用意，其實就是以前說到的 Modular（模塊化、組件化），這樣的好處就是很好的擴展和維護，Interact 能夠理解爲開源帶來的交互和進步，可讓開發者參與，而且反饋問題，利用社區的力量，讓 .NET 更加完善。頗有意思的是，在最後做者舉了一個生活的例子：我認爲這就像駕駛一輛汽車，方向盤小的調整比大的調整，更加有效果，並且也更加安全，這個小的調 整能夠看做是來自社區的那一份份「微小」的力量，大的調整，固然是微軟本身單獨搞，想一想就知道哪一個比較靠譜點。

3. Our choice of using GitHub

這部分也是很是有意思的，首先，微軟作了一個調查，發現大部分的 .NET 社區都活躍在 GitHub 上，Don’t believe it?（看到這，我大笑了三聲），不相信的話，微軟給你舉了一個真實的例子，nuproj（做 者的一個我的項目），在 CodePlex 上放了兩年，僅僅獲得了一個 Pull 請求（想一想也挺傷心的），而後把它移到 GitHub 上，僅僅五天後，就收到了三個 Pull 請求和兩個提交，三個月的時間，總共收到了 16 個 Pull 請求和一些頗有價值的提交。

做者的感覺：one of the first ones was around adding unit testing, how awesome is that? 看來他是很是的激動！

須要注意的是，CodePlex 是微軟構建的 Open Source 網站，它的競爭對手就是 GitHub，而微軟卻如此諷刺本身的「孩子」，而且放棄了它，選擇了別人家的孩子，並把本身的「財產」傳給它，這是須要多麼大的勇氣啊，雖然是迫不得 已，但讓一個巨頭這樣低頭也是一件很可貴的事（此處應該有掌聲）。

4. Development in the open

這部分主要是講微軟如何作開源開發，提到了他們以前作的一個開源項目－Managed Extensibility Framework (MEF)，他們認爲這是失敗的，緣由很簡單，就是缺乏社區的參與，剛纔打開這個項目看了一下，基本上冷冷清清的，沒有一個 Pull 請求（能夠認爲沒人理它），文中提到了一個詞 code bombs， 不知道翻譯爲「代碼炸彈」合不合適？什麼是 code bombs 呢？結合文中的敘述，談一下本身的理解，當開發一個開源項目，其實最重要的就是社區的參與，以及把每一個代碼提交都儘量的細化、規範和公開，由於你不是自 己在開發這個項目，是整個開源社區在作，你須要考慮的更加全面，但每每現實是這樣的，維護團隊由於得不到社區的反饋，開發或修復一個功能沒有及時提交，總 是隔很長的時間進行「整坨」的提交，這時候若是項目出現什麼問題，提交的代碼將會很是的難以查看和修復，並且提交的過程當中不注意規範，最後變成「一坨 X」，也就是「代碼炸彈」，爲了不這種狀況的發生，因此微軟作了如下總結：

• Code reviews. We also want to have all code reviews the team is doing to be in the public as well, via GitHub’s pull request model.

• Design documents & discussions. We’ll also share design notes, specs, and implementation specific documentation. We’ll need to figure out exactly what format we’ll be using. At a minimum you can expect Markdown based documents, similar to Mad’s C# design notes. Another idea we had was recording our design meetings and share them on Channel 9. We need to figure out how we can do this on a somewhat regular cadence.

其實總結就是一個詞：規範化，這樣纔會讓項目更加「健壯」，以後提到了若是出現一些代碼問題，該如何反饋，以及微軟如何進行解決，這個就略過了，若是你發現了一些問題，可使用 GitHub issue 進行反饋，微軟說了，咱們會當即處理，呵呵。

後面又講述了兩點：We accept contributions、Building and running your own forks，主要說明你如何進行代碼提交，奈何本身功力還沒達到這個境界，就此略過。

5. .NET Foundation

.NET Foundation（.NET 基金會）：http://www.dotnetfoundation.org/
.NET Foundation Projects：http://www.dotnetfoundation.org/projects

說明：The .NET Core project is under the stewardship of the .NET Foundation. We believe that to be a critical part in promoting and advancing the .NET Core stack. We’re closely working with Miguel de Icaza from Xamarin/Mono in order to create a shared code base that can become a cross-platform implementation of .NET Core.

上面提到了一我的名：Miguel de Icaza（米格爾·德伊卡薩），他是誰呢？他就是 Mono 的發起人，也是 Mono 團隊的負責人，微軟成立 .NET Foundation 第一步的目的，其實說白了，就是要把 Mono 拉過來，共同把 .NET Core 給維護起來。不少人可能會有這樣的疑問：那 Mono 咋辦？在以前曾提到這樣一段話：The best way to build a cross-platform stack is to build a single stack, in a collaborative manner. And the best way to do exactly that is by open sourcing it.，關鍵詞：single、collaborative manner，這兩個詞就很好的說明了，如今 Mono 與 .NET Core 之間的關係，也就是說他們相互合做，共同維護和管理單一的 .NET 跨平臺實現（.NET Core），這也是社區的共同心願。

6. The relationship between Mono and .NET Core

關於這個問題，上面能夠看到一些答案，咱們再來看一下更多的內容。

首先，在這篇博文中，有人這樣評論：I hope you join forces with the Mono team. Miguel de Icaza has been promoting this for years!

做者回復的是一個 twitter 連接，內容：

若是有時間，能夠再閱讀下這幾篇文章：

• .NET Source Code Integration（來自 Mono 官網）

• Microsoft Open Sources .NET and Mono（做者爲 Miguel de Icaza）

• Introducing .NET Core（跳過前面內容，直接查看 Mono 部分）

摘錄自 .NET Source Code Integration 的部份內容：

We want to contribute some of the cross platform code from Mono, as well as chunks that we port from the .NET Framework Reference Source to the .NET Core effort.
We will update this page with information as the porting process at Microsoft evolves and we can volunteer some of our/their code back to the .NET Core effort.

摘錄自 Microsoft Open Sources .NET and Mono 的部份內容：

The code is available today from http://github.com/Microsoft/referencesource. Mono will be able to use as much a it wants from this project.
We have a project underway that already does this. We are replacing chunks of Mono code that was either incomplete, buggy, or not as fully featured as it should be with Microsoft's code.
With the Mono project, we have spent 14 years working on open source .NET. Having Microsoft release .NET and issue a patent covenant will ensure that we can all cooperate and build a more vibrant, richer, and larger .NET community.

仔細看 Miguel de Icaza 寫的博文內容，你會感覺到他當時的心情，是多麼的激動（I am currently in NY celebrating :-)），後面大部份內容介紹了 Mono 須要作的工做，下面咱們來偵查一下他們是如何進行交互工做的。

文中提到，微軟開源了 Reference Source，referencesource 是什麼？它其實就是 .NET Framework，只不過 GitHub 上並無所有開源，詳情請查看：http://referencesource.microsoft.com/，須要注意的是，這個 .NET Framework 是 Windows 平臺下的，並非咱們所說的 .NET Core 的一部分，Mono 也 Fork 了這個項目，地址爲：https://github.com/Microsoft/referencesource。

咱們再具體隨便看一下 referencesource 項目中一個具體類 System.ComponentModel.DataAnnotations.AssociationAttribute：

01. #if !SILVERLIGHTusing System.Diagnostics.CodeAnalysis;

02.  

03. namespace System.ComponentModel.DataAnnotations {

04. [AttributeUsage(AttributeTargets.Property | AttributeTargets.Field, AllowMultiple = false)]

05. [SuppressMessage("Microsoft.Performance", "CA1813:AvoidUnsealedAttributes", Justification = "We want users to be able to extend this class")]    public class ScaffoldColumnAttribute : Attribute {        public bool Scaffold { get; private set; }        public ScaffoldColumnAttribute(bool scaffold) {

06. Scaffold = scaffold;

07. }

08. }

09.  

10. [AttributeUsage(AttributeTargets.Class, AllowMultiple = false)]

11. [SuppressMessage("Microsoft.Performance", "CA1813:AvoidUnsealedAttributes", Justification = "We want users to be able to extend this class")]    public class ScaffoldTableAttribute : Attribute {        public bool Scaffold { get; private set; }        public ScaffoldTableAttribute(bool scaffold) {

12. Scaffold = scaffold;

13. }

14. }

15. }#endif

對應於 .NET Core 中的實現 System.ComponentModel.DataAnnotations.AssociationAttribute：

01. // Copyright (c) Microsoft. All rights reserved.// Licensed under the MIT license. See LICENSE file in the project root for full license information.namespace System.ComponentModel.DataAnnotations

02. {

03. [AttributeUsage(AttributeTargets.Property | AttributeTargets.Field, AllowMultiple = false)]    public class ScaffoldColumnAttribute : Attribute

04. {        public ScaffoldColumnAttribute(bool scaffold)

05. {

06. Scaffold = scaffold;

07. }        public bool Scaffold { get; private set; }

08. }

09. }

你會發現，.NET Core 中的實現徹底變了，還須要注意的是，在每一個類的上面都有了開源協議說明（MIT license），這個和以前 referencesource 項目是徹底不一樣的，關於代碼更改，這只是項目中的冰山一角，具體你能夠對比查看兩個項目代碼到底有什麼不一樣，有的被移除了，有的被重寫了，這樣改變的目的 就是跨平臺。咱們再看下 Mono 中這部分的代碼（Windows 平臺下），tree 目錄：mono/mono/tree/master/mcs/class/System.ComponentModel.DataAnnotations，查看裏面的目錄結構，沒有發現一個源代碼類文件，只有一些文檔說明和單元測試代碼，難道 Mono 沒有實現嗎？答案固然不是的，查看一下最近的一個代碼提交記錄 https://github.com/mono/mono/commit/c7405e6ca0b5749433c9c7acd49a5a8521ed9094，而後在 System.ComponentModel.DataAnnotations.dll.sources 文件中，發現 Mono 進行了以下更改：

01. ../../build/common/Locale.cs

02. ../../build/common/MonoTODOAttribute.cs

03. Assembly/AssemblyInfo.cs

04. -System.ComponentModel.DataAnnotations/AssociatedMetadataTypePropertyDescriptor.cs

05. -System.ComponentModel.DataAnnotations/AssociatedMetadataTypeTypeDescriptor.cs

06. -System.ComponentModel.DataAnnotations/AssociatedMetadataTypeTypeDescriptionProvider.cs

07. -...+../../../external/referencesource/System.ComponentModel.DataAnnotations/DataAnnotations/AssociatedMetadataTypeTypeDescriptionProvider.cs

08. +../../../external/referencesource/System.ComponentModel.DataAnnotations/DataAnnotations/AssociatedMetadataTypeTypeDescriptor.cs

09. +../../../external/referencesource/System.ComponentModel.DataAnnotations/DataAnnotations/AssociationAttribute.cs

10. +...

返回上級、上級、上級，進入 external/referencesource 目錄，你看到了熟悉的東西，查找到這，你也應該懂了，由於 referencesource 的開源（能夠認爲是 Windows 平臺下的 .NET Framework），因此 Mono 不必用之前本身實現的代碼了，直接使用微軟開源出來的代碼，這是給 Mono 帶來的一個改變，關於上面 .NET Core 這部分的實現代碼，我想微軟也應該參考了 Mono 跨平臺的實現代碼（非 Windows 平臺），從這一方面講，微軟和 Mono 社區是互惠的，就像 Miguel de Icaza 所講的那樣，we can all cooperate and build a more vibrant, richer, and larger .NET community. 其實你們都是爲了 .NET 社區的更好發展，說到這，在他的這篇文章中，有一個有意思的評論（Miguel de Icaza 的回覆也是頗有意思）：

7. The relationship between .NET Core(corefx, CoreCLR) and XRE

咱們先來看一下，微軟在寫那篇文章的時候所列出的一些計劃：

• More libraries. Consider the subset we have today a down-payment on what is to come. Our goal is to open source the entire .NET Core library stack by Build 2015.

• Building and running on non-Windows platforms. We currently only provide the ability to build and run on Windows. We intend to build a public working group between us and the Mono community once we have enough code out there.

• .NET Core Runtime (CoreCLR). We’re currently figuring out the plan for open sourcing the runtime. Stay tuned!

再來看一下如今完成的進度：

• corefx：This repository contains the foundational libraries that make up the .NET Core development stack.

• Roslyn：The .NET Compiler Platform ("Roslyn") provides open-source C# and Visual Basic compilers with rich code analysis APIs.

• XRE：The .NET Cross-Platform Runtime SDK (.NET XRE) contains the code required to bootstrap and run an application, including the compilation system, SDK tools, and the native CLR hosts.

• ....

對比計劃和開源的項目，你能夠往上面套一套了，首先，.NET Core 包含 .NET Core Framework（corefx，部分完成）和 .NET Core Runtime（CoreCLR，暫無），Roslyn 爲跨平臺的編譯器，XRE 是什麼？它是否是微軟未完成的 CoreCLR，其實並非的，咱們再來看開發者提給微軟的一些問題。

1. 連接地址：.NET Core Runtime

問：I've wanted to learn about the .NET runtime for a while and have tried studying Rotor and the spec but haven't gotten very far. I was thinking of retrying with the .NET Core runtime but I can't seem to find it in the GitHub repository.

答：Excellent question. It is really two questions.

• Where/when is CoreCLR? It is in a private repo on GitHub, but it isn't ready yet. We'll switch to public in the first part of next year. The team is focussed on making this happen.
  We've been thinking about how to make it easy for folks to learn about the runtime, in order to understand the code and make quality PRs. We have a bunch of internal documentation that we were thinking about making available in a WH wiki. Sound like a good idea?

• We have a bunch of requirements that are really important to satisfy. On another thread in the forums here, we've been talking about the relationship between .NET Core and the .NET Framework. We need an efficient way to flow code back and forth between .NET Core and the .NET Framework. Getting that right takes time, but will also pay dividends and allow us to take PRs more efficiently once we go public.

We had some of that infrastructure in place when we released the corefx repo, but we learned that it wasn't quite enough. We're taking more time upfront with the coreclr repo.

I'm glad to hear that you and others are excited to see the coreclr repo show up. We are too.

解讀：這個提問者很犀利，直接問爲何在 GitHub 上，找不到 .NET Core Runtime 的項目，原來它被藏起來了（Private），尚未被開放出來，微軟正在加緊時間開發這個東西（最重視的項目），後面說明了 .NET Core and the .NET Framework 之間的關係，目前 corefx 是 .NET Core 的部分實現，等到 coreclr 正式發佈出來，才能夠說它是完整的。

2. 連接地址：.NET Core CLR Questions!

問：Can I embed .NET Core and invoke the runtime like I can with "Embedded Mono"?

答：The CLR has had a public hosting API since its inception. SQL Server and IIS are great examples of CLR hosts. CoreCLR also has a hosting API, which ASP.NET 5 uses. This will be included in the CoreCLR repo, when it shows up.

問：Will .NET Native be open sourced as well so we could port it to other platforms and CPU types? (This would be important to compile .NET on iOS).

答：Right now, we are focussed on CoreCLR. I can imagine .NET Native following. Right now, CoreCLR has all of our attention, so we'll re-visit the .NET Native question after we've got CoreCLR on GitHub.

解讀：第一個問題是，如今能不能像 Mono 同樣啓動 .NET Core，答案是若是使用 ASP.NET 5 是能夠的，由於 ASP.NET 5 已經實現了，那就是 XRE，但 XRE 並非 CoreCLR，它只是 CoreCLR 的一部分（included），第二個問題的答案在後半部分，我沒有貼出來，但這部分答案會讓你對 CoreCLR 有所期待，微軟正在集中力量去開發它，咱們只能期待它早點正式發佈。

8. 有關 .NET 開源的一些其餘疑問（來自文章評論）

1. 問：Does this mean yes or no to open-sourced WPF?

答：We currently don't plan on open sourcing the client stacks, which includes Windows Forms as well as WPF.

暫時沒有計劃開放 Windows Forms、WPF 源代碼，是否是意味着被拋棄？

2. 問：Will I ever be able to run Visual Studio on Linux?

答：I'm not working for Visual Studio but I haven't heard of any plans to offer a cross-platform version of Visual Studio itself.

其實我還想問下 on Mac？呵呵，多但願回答的是 Absolutely，可是仍是很期待微軟能夠實現跨平臺的 Visual Studio，這樣才真正是宇宙最強大的 IDE！

3. 問：Is there a roadmap to "upgrade" WPF to .Net Core 5?

答：There are currently no plans to port either WinForms or WPF to .NET Core.

和第一個問題同樣，微軟沒打算把 WinForms 和 WPF 的代碼添加到 .NET Core 中。

4. 問：does anyone know is plain old WCF a part of CORE?

答：The client side of WCF will be included in .NET Core.

和 WinForms、WPF 相反，WCF 的代碼將會被添加到 .NET Core 中。

5. 問：Immo, ok so all of this is leaving me a bit confused.What does all of this mean for me as an LOB developer?

答：The key difference is that .NET Core will be a single, cross platform stack.

Let's contrast this with .NET Framework and Mono today. Mono is a full reimplementation of the .NET Framework. This means that certain features aren't supported or implemented differently enough to cause behavioral changes that can break your application. Also, Microsoft doesn't support running on Linux or MacOS today.

.NET Core on the other hand will be supported by Microsoft on Windows, Linux and MacOS. We'll have a single code base that we plan on working on together with the Mono community.

For you that means that targeting other platforms will be more reliable and innovation will happen faster. It also means that you'll be able to find out sooner what's coming next because all the design work is happening in public.

Finally, you'll also be able to take a look at the kitchen and engage in design discussion.

這個回答有點囉嗦，主要強調了 Mono 的貢獻，而後再拉着 Mono 一塊作單一的跨平臺 .NET Core，最後就是過程開放。

插一段：including the entire CoreCLR runtime (JIT, GC, etc) as well as a set of class libraries. 能夠看出 .NET Core 大體包含哪些東西。

6. 問：Will everything eventually have an MIT license? Or the Apache 2.0 license? Does it now? I'm confused.

答：Your confusion is very understandable. Some of the .NET open source projects (such as Roslyn) use Apache 2.0. Newer projects (such as .NET Core) use the MIT license. Both licenses are OSI approved open source licenses so either one is indicative of OSS.

Moving forward, we plan on exclusively using the MIT license. I don't know whether we'll switch the existing projects from Apache 2.0 to MIT.

這個是關於開源協議的，咱們能夠經過查看開源項目中，好比類文件的最上面有協議說明，ASP.NET 中大部分項目都是基於 Apache 2.0，最新的開源項目（好比 corefx）是基於 MIT，不知道這兩個協議有什麼不一樣，看做者的意思，微軟是想把 Apache 2.0 協議轉到 MIT 下，不知道可不可行。

7. 問：WebForms on Linux and Mac OS?

答：We're making the .NET Core Framework cross plat, not the .NET Framework and .NET Core doesn't include WebForms.

很簡單，No。

8. 問：does this mean, i will be able to run .net desktop apps on linux, without the original developer having to port to mono?

答：We currently don't plan to open source the client technologies (WinForms, WPF), nor taking them cross plat. So I'm afraid the answer would be no.

很簡單，No plan。

9. 問：What is the relation between .NET Core and .NET Native?

答：.NET Native is two things: it's a tool chain that pre-compiles IL to native and it's a runtime that executes that code. .NET Core is CLI compliant stack that runs both, JIT based applications (via CoreCLR) as well as ahead-of-time compiled (AOT) applications (produced by .NET Native).

這真是一個好問題，什麼是 .NET Native？它最大的特色，是能夠直接將應用程序代碼編譯成本地機器碼，這是和 .NET Core 最大的區別，因此做者提到了 CLI compliant，這部分在上面 Mono 中有說明。

10. 問：You said that the client side of WCF will be included in .NET Core. What about the server side of WCF? I mean .NET Core will be a Server side technology if I understand correctly

答：That's an execellent question for the WCF team. I'll forward that question.

這個上面有個問題搞錯了，「client side of WCF will be included in .NET Core」，注意是 Client，而並非 Server，這個兩個不一樣的概念，Client 的做用就是爲了兼容以前開發的 WCF 項目。

11. 問：.NET Core Runtime is the same runtime which .NET Framework uses?

答：.NET Core has two runtimes: CoreCLR and .NET Native.

CoreCLR isn't identical to the CLR but it's very close. The key pieces are virtually identical, so same GC, same JIT, same type system etc.

In .NET Native, it's obviously a lot more different as .NET Native doesn't have a JIT, but the GC, for example, is the same.

How close is .NET Core Runtime to Mono Runtime?

They are different implementations, done by different people. But both implement the same ECMA CLI standard, so they are quite similar in what they do, but most likely not in how they do it.

好問題，好回答，CoreCLR 和 .NET Native 是徹底不一樣的模式，.NET Native 由於直接能夠講程序代碼編譯成本地機器碼，因此根本不須要 JIT，另一個問題是 .NET Core Runtime 和 Mono Runtime，首先他們是不一樣的實現，但他們都是基於 ECMA CLI（公共語言基礎），他們的類似之處都是將 CIL 編譯成本地機器碼。

---

前段時間，dudu 寫了一篇這樣的博文：擋不住的好奇心：ASP.NET 5是如何經過XRE實現跨平臺的，最後產生了這樣一個疑問：在 Core CLR 被加載，Microsoft.AspNet.Hosting 被執行以後，爲何還要用 Mono Runtime 加載一些 dotnet.host 相關的程序集？爲何不直接用 Core CLR 加載呢？

其實 XRE 並非真正的 .NET Core Runtime，能夠說是它的一部分，或者是一個先行版本，爲何要藉助 Mono Runtime？很簡單，由於 .NET Core Runtime 並不完善，我相信微軟和 Mono 社區如今正在加緊完善這個最重要的項目 coreclr，至於 .NET Core Framework（corefx）的開發，有了微軟的 Windows .NET Framework 和 Mono 自行實現的跨平臺 .NET Framework，其實移植到 corefx 的難度並不大，重要的仍是 coreclr，請注意這個連接地址：https://github.com/dotnet/coreclr，說不許過幾天就不是「404」了，期待吧！

若是你能堅持看到這裏，我真是感激不盡！！！