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

當時大概愣了好久，好像也沒說出個所以然，得到的回覆是：這是 .NET 程式設計師最基本的。。。呵呵！

微軟開源，其實不只是對 .NET 本身有利，從另一方面講，對於 .NET 程式設計師來說，因為開源，你可以想了解到你想要的任何事。在之前的歲月，你可以“平凡”做一個默默無聞的 C# 程式碼撰寫者，可以不用考慮任何事，使用宇宙最強大的 IDE - Visual Studio 編寫程式碼後，釋出到 IIS 即可，就是這麼簡單，甚至你不需要知道 IIS 是怎麼執行的，程式碼是怎麼託管的等等，你只需要寫好你的 C# 程式碼即可，因為其餘的一切工作，微軟已經幫你考慮並完成了。這樣雖然簡單並且高效，但對於 .NET 程式設計師來說，這就像“井底之蛙”一樣，你看不到外面的世界，你也沒有任何動力去跳出這個“深井”，而只是“舒適”的觀望著外面你所認為的“狹隘世界”。但因為開源、跨平臺，這些平靜的日子都將被打破了，微軟開源出來的一個個專案、發表的一篇篇文章，怎麼越來越看不懂了？最後才發現，現在的微軟已經不是原來我們熟悉的那個微軟了，.NET 亦是如此。

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

在很久很久之前，如果提到 .NET 跨平臺，你首先想到的應該是 Mono，那 Mono 到底是什麼？它為什麼可以跨平臺？在 .NET 開源之前，我對這些是一無所知，理解微軟這次 .NET 跨平臺，需要首先了解 Mono，瞭解 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 開源的一篇官方說明文章，內容很多（包括評論），如果你真正花時間去讀的話，這篇文章的資訊量是非常大的，下面是我搜刮的一些片段。

.NET Core 包含：

編譯器、ASP.NET：

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

說明：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!

如果有時間，可以再閱讀下這幾篇文章：

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.

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。

#if !SILVERLIGHT
using System.Diagnostics.CodeAnalysis;

namespace System.ComponentModel.DataAnnotations {
    [AttributeUsage(AttributeTargets.Property | AttributeTargets.Field, AllowMultiple = false)]
    [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) {
            Scaffold = scaffold;
        }
    }

    [AttributeUsage(AttributeTargets.Class, AllowMultiple = false)]
    [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) {
            Scaffold = scaffold;
        }
    }
}
#endif

// 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
{
    [AttributeUsage(AttributeTargets.Property | AttributeTargets.Field, AllowMultiple = false)]
    public class ScaffoldColumnAttribute : Attribute
    {
        public ScaffoldColumnAttribute(bool scaffold)
        {
            Scaffold = scaffold;
        }

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

../../build/common/Locale.cs
 ../../build/common/MonoTODOAttribute.cs
 Assembly/AssemblyInfo.cs
-System.ComponentModel.DataAnnotations/AssociatedMetadataTypePropertyDescriptor.cs
-System.ComponentModel.DataAnnotations/AssociatedMetadataTypeTypeDescriptor.cs
-System.ComponentModel.DataAnnotations/AssociatedMetadataTypeTypeDescriptionProvider.cs
-...
+../../../external/referencesource/System.ComponentModel.DataAnnotations/DataAnnotations/AssociatedMetadataTypeTypeDescriptionProvider.cs
+../../../external/referencesource/System.ComponentModel.DataAnnotations/DataAnnotations/AssociatedMetadataTypeTypeDescriptor.cs
+../../../external/referencesource/System.ComponentModel.DataAnnotations/DataAnnotations/AssociationAttribute.cs
+...

返回上級、上級、上級，進入 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，其實並不是的，我們再來看開發者提給微軟的一些問題。

問：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 正式釋出出來，才可以說它是完整的。

問：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”了，期待吧！

如果你能堅持看到這裡，我真是感激涕零！！！