介紹.NET Core

　　在connect ()，我們宣布.NET 核心将能完全釋放，作為開放源碼軟體。我也答應在.NET 核心跟更多的細節。在這篇文章，我将提供.NET 核心，我們如何去釋放它，它涉及到.NET 架構，如何和這意味着跨平台和開放源代碼發展概況。

回望 — — 激勵.NET Core

第一次讓我們回頭來了解.NET 平台如何打包在過去。這有助于激勵的一些決定和結果建立了.NET 核心的想法。

.NET — — 這一套的縱向市場

我們最初在 2002 年發運.NET 架構時隻有一個單一的架構。不久之後，我們釋出了.NET 架構精簡版是适合更小的裝置，專門為 Windows Mobile 足迹.NET 架構的一個子集。緊湊的架構是一個單獨的代碼庫從.NET 架構。它包括整個垂直: 運作庫、 架構和應用程式模型頂上的。

自那時以來，我們已經多次這個子集練習: Silverlight，Windows Phone 和大多數最近為 Windows 應用商店。這會産生碎片，因為.NET 平台并不是一個單一的實體，但一套平台，由不同的團隊，擁有和保持獨立。

當然，還有什麼毛病提供專門的功能以滿足特定的需要。但它成為一個問題，如果沒有系統的方法和專業化發生在很小的在其他垂直的相應層沒有顧及每一層。結果是一組隻分享事實，他們開始從常見的代碼庫的 Api 的平台。随着時間的推移這将導緻更多分歧除非顯式 (且昂貴) 的措施采取收斂的 Api。

破碎的問題是什麼?如果你隻針對單個垂直然後真的沒有任何問題。你提供了一個 API 集，就是優化您的垂直。隻要你想要的目标水準，這是多個垂直産生了問題。現在，你必須有可用的 Api 的理由和拿出一種方法來産生你想要的目标的垂直跨工作的資産。

今天它是極為平常的事情有跨裝置的應用程式: 那裡是幾乎總是運作在 web 伺服器上，往往是行政的前端使用 Windows 桌面和一組暴露給消費者，可供多個裝置的移動應用程式的後端。是以，它是關鍵以支援開發人員建構可以跨所有的.NET 垂直的元件。

可移植類庫的誕生

最初，是代碼的跨行業共享沒有概念。沒有可移植類庫，沒有共享的項目。你基本上被困與建立多個項目，連結的檔案和

#if

。這使得針對多個垂直一個艱巨的任務。

在 Windows 8 周期中我們趕上了一項計劃來處理這個問題。當我們設計的 Windows 應用商店配置檔案我們引入了新的概念模型的子集在更好的方式: 合同。

原來，.NET 架構就被圍繞假設作為一個單一的機關，部署了始終，是以保理業務并不關心。一切取決于核心大會是 mscorlib。Mscorlib.NET 架構提供的包含許多功能不能支援無處不在 (例如，遠端處理和 Appdomain)。這迫使每個垂直子集平台的核心。這使它非常複雜工具讓你的目标多個垂直類圖書館經驗。

觀念上的合同是提供構造良好的 API 表面積。合同是簡單地反對編譯的程式集。與正常程式集合同程式集是圍繞适當保理業務設計的。我們深切關注這些依賴項之間的合同，他們隻有一個單獨的職責，而不是被抓包的 Api。獨立合同版本和遵循正确的版本控制規則，如添加 Api 結果在較新版本的程式集。

我們用合同來跨所有縱向市場模型 API 集。垂直可以然後簡單地選擇他們想要支援的合同。一個重要方面是垂直必須支援合同，批發或根本沒有。換句話說，他們不能子集的合同内容。

這允許推理關于垂直在程式集級别，而不是我們以前單個 API 級别的 API 差異。這一方面使我們能夠提供可以針對多個行業，也被稱為可移植類庫的類圖書館經驗。

統一與統一執行 API 形狀

可以将可移植類庫看作結合基于其 API 形狀的不同.NET 垂直的經驗。解決這個問題最迫切的需要，這是建立在不同.NET 垂直運作的庫的能力。它還擔任設計工具到驅動器收斂之間垂直，例如，Windows 8.1 和 Windows Phone 8.1 之間。

然而，我們仍然有不同的實作 — — 或叉 — —.NET 平台。那些實作由不同團隊，版本獨立，并有不同的運輸車輛。這使得統一 API 形狀不斷面臨的挑戰: API 隻是便攜式時執行跨所有的垂直向前移動，但由于代碼庫的不同，是相當昂貴，是以總是服從 (稀土) 确定優先次序。即使我們可以做一個完美的工作，通過收斂 Api: 所有垂直都有不同的運輸車輛，這意味着對生态系統的某些部分将總是落在後面。

更好的方法統一實作: 而不是隻提供一個構造良好的看法，我們應該提供一個構造良好的實作。這将允許垂直簡單分享相同的實作。收斂将不再是額外的;它被通過建設。當然，還有一些情況下我們可能需要多個實作的地方。檔案 I/O，這需要使用不同的技術，基于環境是一個很好的例子。然而，它是要問每個團隊擁有特定的元件，想想他們的 Api 跨所有縱向市場比試圖追溯提供一緻的 API 堆棧頂部的工作簡單得多。這是因為可移植性不是一個什麼東西你可以稍後提供。例如，我們的檔案 Api 包括支援為 Windows 通路控制清單 (ACL)，不能在所有環境中支援。Api 的設計必須考慮這問題，和，例如，在不支援 Acl 的平台上提供此功能在一個單獨的程式集，可以省略。

全機的架構與本地應用程式架構

另一個有趣的挑戰就是要與.NET 架構如何部署。

.NET 架構是一個機全架構。對它所做的任何更改會影響所有應用程式都以它的依賴項。有一個機器全架構是一個深思熟慮的決定，因為它解決了這些問題:

1. 它允許集中服務
2. 它減少了磁盤空間
3. 允許共享應用程式之間的本機映像

但它也是需要付出代價。

其一，它複雜應用程式開發人員對最近公布的架構采取一個依賴項。你必須帶上最新的作業系統依賴項或提供應用程式的安裝程式能夠安裝.NET 架構時安裝的應用程式。如果你是一個 web 開發者你可能甚至沒有此選項因為 IT 部門告訴你允許你使用哪個版本。如果你是移動開發者你真的沒有選擇，但您的目标作業系統。

但即使你願意通過提供安裝程式，以便在.NET 架構安裝鍊的麻煩，你可能會發現更新.NET 架構可以破壞其他應用程式。

堅持 — — 我們不說我們的更新高度相容嗎?我們都是。并且我們非常認真的相容性。我們有為對.NET 架構所做的任何更改進行嚴格的稽核。任何可能被重大更改為我們有專門的審查調查的影響。我們運作相容實驗室，在這裡我們測試許多流行.NET 應用程式，以確定我們不回歸他們。我們也有能力告訴應用程式編譯的.NET 架構。這使我們能夠保持與現有應用程式的相容性，同時，選擇到最終目标較新版本的.NET 架構為應用程式提供更好的行為。

不幸的是，我們還學甚至相容的更改可以中斷應用程式。讓我舉幾個例子:

• 将接口添加到現有的類型可以中斷應用程式，因為它可能會幹擾類型如何被序列化。
• 以前并沒有任何重載方法中添加重載可以打破從來沒有處理發現超過一個方法的反射消費者。
• 重命名一個内部類型可以中斷應用程式，如果該類型名稱通過 tostring () 方法浮出水面。

那些是都罕見的情況下，但當你有 18 億機器相容的 99.9%的客戶群可以仍然意味着 180 萬機受到影響。

更有趣的是，在許多情況下修複受影響的應用程式是相當瑣碎的。但問題是，應用程式開發人員并不一定涉及中斷發生時。讓我們看看一個具體的例子。

您測試您的應用程式，.NET 架構 4 上，這是您與您的應用程式的安裝。但一些第一天的您的客戶安裝另一個應用程式更新到.NET 架構 4.5 的機器。你不知道您的應用程式是破碎的直到該客戶調用您的支援。在這一點上處理您的應用程式的相容問題是軟體的相當昂貴的因為你必須得到相應的源、 設定攝制機、 調試應用程式，進行必要的更改，他們融入釋出分支，産生新版本，測試它，和終于釋出更新為您的客戶。

這與您決定您想要利用在較新版本的.NET 架構釋出功能在哪裡的情況形成對比。在這一點上在發展過程中，你已經準備好對您的應用程式進行更改。如果有一個輕微的相容故障，你可以輕松地處理它作為功能工作的一部分。

由于這些問題，我們花一段時間來釋出一個新版本的.NET 架構。更激烈的變化，更多的時間，我們需要烤它。這個結果在自相沖突的情況，在那裡我們測試版已經相當鎖定了，我們幾乎無法采取設計更改請求。

兩年前，我們已經開始船上 NuGet 庫。因為我們沒有将這些庫添加到.NET 架構我們将他們稱為"帶内"。帶外庫不患上我們隻是讨論，因為它們是應用程式本地的問題。換句話說，庫部署，如果他們是您的應用程式的一部分。

這很大程度解決了阻止您更新到較新版本的所有問題。你采取較新版本的能力隻限制的能力，釋放您的應用程式的更新版本。這也意味着你在控制哪個版本的圖書館正在利用特定的應用程式。更新完成而不會影響在同一台機器上運作的其他應用程式在單個應用程式的上下文中。

這使我們能夠釋出的更新，以更加靈活多樣的方式。NuGet 還提供預覽版本，讓我們釋放位尚未送出特定 API 或行為上的概念。這支援工作流，在那裡我們可以提供你與我們最新的設計，以及 — — 如果你不喜歡它 — — 隻是更改它。很好的例子，這是不變的集合。它有約九個月的試用期間。我們花了很多時間試圖獲得正确的設計之前我們發貨的第一版本。不用說決賽設計 — — 感謝你提供 — — 的廣泛回報方式比初始版本要好。

輸入.NET 核心

所有這些方面使我們重新思考和改變的造型向前的.NET 平台的方法。這導緻在.NET 核心創作:

.NET 核心是可以用在各種各樣的垂直縮放從觸摸基于的裝置的資料中心的子產品化實作是可用作為開放源碼和支援由微軟 Windows、 Linux 和 Mac OSX 上。

讓我走進的如何.NET 核心看起來像，它是如何解決問題我前面讨論的更多細節。

為.NET 本機和 ASP.NET 的統一的實施

當我們設計.NET 本機很顯然我們不能使用.NET 架構為基礎的架構類庫。這是因為.NET 本機基本上合并與應用程式架構，然後再移除碎片，不需要由應用程式之前它生成的本機代碼 (我大大簡化這一過程在這裡。有關更多詳細資訊，看看這深潛)。正如我剛才所說，.NET 架構執行不考慮使得它極具挑戰性，連結器以減少多少架構擷取編譯成應用程式 — — 依賴封閉是太大。

ASP.NET 是 5 面臨類似的挑戰。盡管它不使用.NET 本機新的 ASP.NET 5 web 堆棧的目标之一是提供 XCOPY 部署堆棧，使 web 開發人員沒有與他們的 IT 部門協調，以便能依賴更高版本。在這種情況下它也是重要的是盡量減少架構的大小，因為它需要與應用程式一起部署。

.NET 核心是本質上叉 NET 架構的執行也優化周圍保理業務的關注。盡管.NET 本機 (基于觸摸裝置) 和 ASP.NET 5 (伺服器端 web 開發) 的情況是完全不同，我們都能提供統一基類庫 (BCL)。

為.NET 核心 BCL API 表面積是相同自這兩個.NET 本機以及 ASP.NET 5。底部的 BCL 我們有特定于.NET 運作時非常薄層。我們目前有兩種實作方式: 一是特定于本機.NET 運作時和一種特定于 CoreCLR，使用 ASP.NET 5。然而，該圖層不經常改變。它包含類型，如字元串和 Int32。BCL 絕大多數是純 MSIL 程式集可以作為共享-是。換句話說，Api 不隻是看起來相同 — — 它們共享相同的實作。例如，就沒有理由要集合的不同實作。

BCL，此外還有應用程式模型特定 Api。例如，.NET 本機方面提供特定于 Windows 用戶端開發，如 WinRT 互操作的 Api。ASP.NET 是 5 添加如 MVC 是特定于伺服器端 web 開發的 Api。

我們認為.NET 核心不是特定于.NET 本機的也 ASP.NET 5 — — BCL 和運作時環境是一般用途為子產品化設計。是以，它的基礎為所有未來的.NET 縱向市場。

NuGet 作為第一類運載工具

與.NET 架構，将作為一組 NuGet 包傳遞.NET 核心平台。我們已經落在 NuGet因為這是絕大多數圖書館生态系統已經在哪裡。

為了繼續我們的子產品化和構造良好的努力我們不隻是作為一個單一的 NuGet 包提供整個.NET 核心平台。相反，它是一套的細粒度 NuGet 程式包:

BCL 層，我們将有 1 對 1 關系之間的程式集和 NuGet 程式包。

向前，NuGet 包将具有相同的名稱的程式集。例如，不可變集合不再會在一個叫做Microsoft.Bcl.Immutable的 NuGet 包傳送但相反被稱為System.Collections.Immutable的包中.

此外，我們已經決定為我們的程式集版本控制使用語義版本控制。NuGet 軟體包的版本号将程式集版本與對齊。

命名和版本控制的程式集和包之間的對齊方式極大地幫助與發現。不再是神秘的 NuGet 程式包包含 System.Foo，版本 = 1.2.3.0 — — 它由 System.Foo 包 1.2.3 版本中提供。

NuGet 允許我們以靈活的方式傳遞.NET 核心。是以如果我們提供更新到任何 NuGet 程式包，您可以簡單地更新相應的 NuGet 參考。

提供架構本身對 NuGet 還會移除表示 1 方.NET 依賴項之間的差異和第三方依賴關系 — — 它們是所有 NuGet 依賴項。這使第三方包來表達，例如，他們需要較高版本的 System.Collections 圖書館。安裝此第三方包現在可以提示您更新您對 System.Collections 的引用。你不需要了解的依賴關系圖 — — 你隻需要同意對它進行更改。

NuGet 基于交貨也變成一個本地應用程式架構的.NET 核心平台。.NET 核心的子產品化設計保證了每個應用程式隻需要部署它的需要。我們也正在啟用智能共享，如果多個應用程式使用相同的架構位。然而，目标是確定每個應用程式邏輯上有它自己的架構，以便更新不會幹擾其他應用程式在同一台機器上運作。

我們決定使用 NuGet 作為一種傳遞機制不會改變我們對相容性的承諾。我們繼續極其認真的相容性并不會一旦包标記為穩定執行 API 或行為的重大更改。然而，應用程式本地部署確定在哪裡是變化視為添加劑中斷應用程式的情況很少是孤立發展時間隻。換句話說，為.NET 核心這些工間休息隻能發生在你更新包的引用後。在那一刻，你有兩個選項: 解決在應用程式中的故障，相容或復原到以前的版本的 NuGet 包。但.NET 架構與那些斷裂不會發生後你部署到客戶或生産伺服器應用程式。

企業準備好了

NuGet 部署模型使靈活版本和更快的更新。然而，我們不想妥協，.NET 架構提供了今天的一站式服務經驗。

.NET 架構的偉大的事情之一就是它作為一個整體單元，這意味着微軟測試和支援所有元件作為一個單一的實體的船隻。為.NET 核心我們将提供相同的體驗。我們将建立一個.NET 核心分布的概念。這基本上是隻是一個快照中我們對它們進行測試的特定版本的所有軟體包。

這個想法是，我們的團隊通常擁有單個的軟體包。航運的團隊的包的新版本隻需要團隊測試他們的元件，在他們所依賴的元件的上下文中。因為你可以混合和比對 NuGet 程式包顯然可以在某些元件的組合不好一起玩的情況。分布不會有這問題，因為所有元件在組合進行都測試。

我們期望分布在較低的節奏比單個包裝發運。我們目前正在考慮一年四次。這允許為時間，它會帶我們去運作必要的測試，确定簽字。

雖然.NET 核心傳遞作為一套的 NuGet 程式包并不意味着你必須下載下傳軟體包每次你需要建立一個項目。我們會為分布提供脫機安裝程式，還包括他們與 Visual Studio，以便建立新的項目将會像今天一樣快速和不需要網際網路連接配接在發展過程中。

雖然應用程式本地部署非常适合隔離的影響，走上較新的功能的依賴項它并不适用于所有情況。關鍵的安全修補程式必須快速部署和全面的秩序才能有效。我們都充分緻力于使安全修補程式，因為我們總是對.NET。

為了避免相容性問題，我們已經看到在過去與.NET 架構集中更新至關重要的這些唯一目标的安全漏洞。當然，還有那些破壞現有應用程式的機會很小。這就是為什麼我們隻有這樣做的真正關鍵的問題，它是能接受使一組非常少的不再工作而不是所有的應用程式使用此漏洞運作的應用程式。

基礎打開源和跨平台

以.NET 跨平台以可持續的方式，我們決定到開源.NET 核心.

從過去的經驗我們明白成功的開放源碼是它周圍的社群功能。對此的一個關鍵方面是開放和透明的發展過程，使社群參與代碼審查，讀設計檔案，并協助對産品的更改。

開放源代碼使我們能夠擴充.NET 統一，跨平台開發。如果基本的元件，如集合需要執行多次積極痛生态系統。.NET 核心的目标擁有一個單個代碼庫，可以用于建構和支援所有平台，包括 Windows、 Linux 和 Mac OSX。

當然，某些元件，如檔案系統，需要不同的實作。NuGet 部署模型允許我們抽象掉這些差異。我們可以有一個單一的 NuGet 包，提供了一個用于每個環境的多個實作。然而，重要的部分是，這是此元件的實作細節。所有消費者都看到一個統一的 API，它發生在所有的平台工作。

另一種方式來看看這個是欲望的開放源碼是欲望的延續我們釋放.NET 元件用靈活的方式:

1. 開放源碼提供準實時通信技術的實施和總體方向
2. 釋放到 NuGet.org 軟體包提供在元件級靈活
3. 發行版提供平台一級靈活性

在所有三個元素使得我們能夠提供廣泛的靈活性和成熟。

與現有平台的.NET 核心關系

雖然我們設計.NET 核心，它将成為未來的所有堆棧的基礎，我們非常了解建立"一個通用堆棧"，每個人都可以使用的困境:

我們相信我們找到的未來奠定了基礎，同時保持與現有堆棧大互操作性的良好平衡。我去看幾個這些平台更多的細節。

.NET 架構 4.6

.NET 架構仍是選擇建構豐富的桌面應用程式的平台和.NET 核心不會改變的。

視覺工作室 2015 年我們的目标是確定.NET 核心是.NET 架構的一個純子集。換句話說，應該不會有任何功能差距。視覺工作室 2015年釋出之後我們的期望是.NET 核心将快于.NET 架構的版本。這意味着功能将隻在基于.NET 核心平台上可用的時間，将點。

我們将繼續釋放對.NET 架構的更新。我們目前的想法是，釋放節奏将大緻相同的今天，這是每年一次。在這些更新，我們會帶我們在.NET 核心向.NET 架構的創新。我們将不隻是盲目地港口各項功能的工作，雖然 — — 它将基于成本效益分析。正如我所指出的.NET 架構甚至添加劑更改可以導緻現有應用程式的問題。我們的目标是盡量減少 API 和行為上的差别，同時不打破現有的.NET 架構應用程式的相容性。

也有專門正在進行的工作，我們在WPF 路線圖公布.NET 架構的投資.

單聲道

你們很多人問單跨平台故事.NET 核心意味着什麼。Mono 項目是本質上是開放源碼的重新實作.NET 架構。它與.NET 架構分享了豐富的 Api，但也有一些問題，特别圍繞執行保理業務。

單是活着，很好用頂上一個大的生态系統。這是為什麼，獨立的.NET 核心，我們也釋出了.NET 架構參考源下打開源友好的許可，在 GitHub 上部分。這樣做的目的是為了使單聲道社會能夠使用相同的代碼關閉.NET 架構和單聲道之間的差距。不過，.NET 架構的複雜性我們不是安裝在 GitHub 上運作它作為一個開放源代碼項目。尤其是，我們無法為它接受的請求。

另一種方式，看看它:.NET 架構具有本質上是兩把叉子。一把叉子由微軟提供，隻是 Windows。其他叉是聲道，你可以使用 Linux 和 mac。

與.NET 核心我們能夠制定整個.NET 堆棧作為一個完全開放源碼項目。是以，不必維護單獨的叉子将不再有必要: 與單聲道社會我們會大力.NET 核心 Windows、 Linux 和 Mac OSX。這也使單聲道的社群創新在精簡的.NET 核心堆棧，以及考慮到微軟不感興趣的環境。

Windows 應用商店與 Windows Phone

Windows 商店 8.1 和 Windows Phone 8.1 平台有很多較小的.NET 架構子集。然而，他們也是.NET 核心的子集。這使我們能夠使用.NET 核心作為兩個向前這些平台的底層實作。是以如果你正在為這些平台将能夠直接消耗所有的創新，而無需等待更新的架構。

這也意味着 BCL Api 在這兩個平台上可用的數量将與那些你可以看到在 ASP.NET 5 今天完全相同。例如，這包括非泛型集合。這将使它更便于你帶到觸摸基于應用程式體驗在.NET 架構上運作的現有代碼。

另一個明顯的副作用是 Windows 應用商店和 Windows Phone 中的 BCL Api 完全收斂和底層的.NET 平台現在是兩個由.NET 核心供電将繼續融合。

.NET 核心和其他.NET 平台之間共享代碼

由于.NET 核心奠定了未來的所有.NET 平台代碼與.NET 核心基于共享平台已成為無摩擦。

這裡的問題代碼共享如何使用不基于.NET 的核心，如.NET 架構的平台。答案是: 它像今天一樣，你可以繼續使用便攜式類庫和共享的項目:

• 便攜式類庫是偉大的當你常見的代碼是獨立于平台的以及作為可重用的庫位置的特定于平台的代碼可以被分解。
• 共享項目是代碼的偉大，當你常見的代碼有幾位的特定于平台，因為你可以适應它與

  #if

  .

為更多細節兩者之間選擇，看看這篇部落格.

在向前邁進，便攜式類庫還将支援針對.NET 核心的基礎平台。唯一的差別是，如果你隻有目标.NET 核心基礎平台你不要一套固定的 API。相反，它基于的 NuGet 程式包，您可以在更新将。

如果您還不基于.NET 核心的至少一個平台，你被受到可以共享它的 Api。在此模式下，你仍然能夠更新 NuGet 程式包，但可能會提示您選擇更高的平台版本或完全放棄對他們的支援。

這種方法允許您共存在兩個世界同時也獲得了.NET 核心帶來的好處。