參考頁面： http://www.yuanjiaocheng.net/ASPNET-CORE/core-middleware.html http://www.yuanjiaocheng.net/ASPNET-CORE/core-exception.html http://www.yuanjiaoch ...
參考頁面：
http://www.yuanjiaocheng.net/ASPNET-CORE/core-middleware.html
http://www.yuanjiaocheng.net/ASPNET-CORE/core-exception.html
http://www.yuanjiaocheng.net/ASPNET-CORE/core-static-files.html
http://www.yuanjiaocheng.net/ASPNET-CORE/setup-mvc.html
http://www.yuanjiaocheng.net/ASPNET-CORE/mvc-design-pattern.html
自從年前用 ASP.NET 5 磕磕絆絆重寫了一個項目後 （2015.12），就沒怎麼關註 ASP.NET 5 相關內容了，為啥？因為實際應用問題太多，而且不是正式版本，變化實在太快，可能你今天瞭解的東西，明天就被否定了，但現在回過頭看，不關註的話就會漏失一些有價值的東西，雖然看看新聞瞭解到了，但還應該去深入的思考下，並且經歷微軟開源一步一步走向成熟的過程，這對於我們來說，也是一個機遇。
這段時間，我覺得主要發生了兩件事：
對我們影響最大的是 ASP.NET 5 重命名為 ASP.NET Core 1.0，我簡單列舉幾個：
- 搜索資源不匹配，我應該是搜 ASP.NET vNext？還是 ASP.NET 5？還是 ASP.NET Core 1.0 呢？並且以前寫的有關文章資料，都搜索不到了。
- 程式包名稱變化，這個對已經用 ASP.NET 5 開發的項目影響最大，比如
Microsoft.AspNet.Mvc變成了Microsoft.AspNetCore.Mvc.Core，相關程式集名稱都需要更改。 - 運行命令變更（包含運行時），主要是增加新的東西 CLI，比如
dnu restore變成了dotnet restore等等。 - ...
上面是對於我們開發者所造成的影響，其實對於微軟來說，重命名所帶來的額外工作也非常大，這也就造成了 ASP.NET Core 發佈日期的推遲，就像新聞中所提到的：這是個很好的改變，但為什麼來得這麼遲呢？如果像 ASP.NET vNext 改名為 ASP.NET 5 那麼迅速就好了。
除了 ASP.NET Core 1.0 重命名外，我覺得還有一個最大的變化，就是 dnx 到 cli 的改變，這部分內容需要深入探討下，在探討之前，大家可以先看下這篇博文：K & DN 的前世今生（微軟開源命名變革）
- k -> dotnet -> dn（最終版）
- kpm -> dotnet -> nuget -> dotnpm -> dotnetpm -> dnpm（最終版）
- kvm -> dotnetsdk -> dotnvm -> dotnetvm -> dnvm（最終版）
- k and kvm -> dotnet -> 合併（否決）
- kre/xre -> dnx（未經討論確定）
上面是很久之前 GitHub 上一個命名討論的 Issue，現在回過頭看，是不是很有意思呢，因為大家一開始探討的命名就是現在微軟的命名，微軟實在做了太多無用功，cli 是從 dnx 變遷過來的，我們先瞭解下 dnx 是什麼？
The DNX (a .NET Execution Environment) contains the code required to bootstrap and run an application, including the compilation system, SDK tools, and the native CLR hosts.
說白了，我覺得 dnx 就是 ASP.NET 5 應用程式的運行時（某段時間內），為什麼這樣說？我們先瞭解下 dnx 的歷程，dnx 最初被命名為 xre，然後又被命名為 kre，需要註意的是，那時候還沒有 CoreCLR，詳見《魅力 .NET：從 Mono、.NET Core 說起》的文章最後，xre 中的代碼並不是很完善，有很多的代碼都是從 mono 借鑒過來的，包括運行時都是 mono，所以，看上面 dnx 的介紹，它其實就是一個運行時，並且因為 dnx 不是很完善，圍繞它的命令也就改來改去。
後來微軟開發了 CoreCLR，它是一個微軟自己的運行時，GitHub 地址不再放在 aspnet 下，而是放在了 dotnet 下，但其實是 CoreCLR 並不是很完善，從開源地址貼出來後，就一直在開發的狀態，並不能真正的拿來使用 （跨平臺），所以 dnx 一直被 ASP.NET 5 使用著，但後來隨著 CoreCLR 的逐步完善，微軟就開始考慮拋棄 dnx 了，cli 也就誕生了。
需要註意的是，cli 並不是由 dnx 重命名來的，而是演化過來的，它們倆是兩個完全不同的概念，另外，cli 也不是公共語言基礎（Common Language Infrastructure）的簡寫，而是 .NET Core Command Line Interface，翻譯過來就是 .NET Core 命令行介面。
CLI, This repo contains the .NET Core command-line (CLI) tools, used for building .NET Core apps and libraries through your development flow (compiling, NuGet package management, running, testing, ...).
This repo contains the source code for cross-platform .NET Core command line toolchain. It contains the implementation of each command, the native packages for various supported platforms as well as documentation.
上面和 dnx 的定義對比下，就會發現它們是完全不同的，那 cli 到底包含哪些內容，在上面已經有了詳細的解釋，.NET Core 命令行介面及其實現，它的作用就是在應用程式和運行時之間搭起一座溝通橋梁，命名形式以dotnet *開始，我覺得 cli 是微軟以後所有命令實現的一種規範，應該不會再出現雜七雜八的命令了。
最後，看一段 About .NET Core 的內容：
.NET Core is a cross-platform implementation of .NET that is primarily being driven by ASP.NET 5 workloads, but also by the need and desire to have a modern runtime that is modular and whose features and libraries can be cherry picked based on the application’s needs.
.NET Core consists of the CoreCLR runtime and the CoreFX framework libraries. A set of cross-platform tooling can be found in the .NET CLI. The Roslyn compiler and LLILC compiler are sibling projects that support .NET Core. These projects are active on GitHub. You can participate by creating issues or collaborate on development. The main goal of the project is to create a modular, performant and cross-platform execution environment for modern applications.
.NET Core 一開始是 ASP.NET 5 跨平臺的一種實現，後來被逐步變化為 .NET 跨平臺的核心運行時，.NET Core 包含 CoreCLR 和 CoreFX，一個 .NET CLI，Roslyn 和 LLILC 編譯器，主要目標：modular（模塊化）、performant（高性能）和 cross-platform execution environment（跨平臺執行環境）。
關於高性能，可以看看最近的這篇新聞：《ASP.NET Core 每秒能處理 115 萬個請求，是 ASP.NET 4.6 的 23 倍（5 萬個請求）》，另外，ASP.NET Core 1.0 的應用示例：《ASP.NET Core 1.0 Hello World》
