在connect ()，我們宣布.NET 核心將能完全釋放，作為開放源碼軟件。我也答應在.NET 核心跟更多的細節。在這篇文章，我將提供.NET 核心，我們如何去釋放它，它涉及到.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 形狀的不同.NET 垂直的經驗。解決這個問題最迫切的需要，這是創建在不同.NET 垂直運行的庫的能力。它還擔任設計工具到驅動器收斂之間垂直，例如，Windows 8.1 和 Windows Phone 8.1 之間。
然而，我們仍然有不同的實現 — — 或叉 — —.NET 平台。那些實現由不同團隊，版本獨立，並有不同的運輸車輛。這使得統一 API 形狀不斷面臨的挑戰: API 只是便攜式時執行跨所有的垂直向前移動，但由於代碼庫的不同，是相當昂貴，因此總是服從 (稀土) 確定優先次序。即使我們可以做一個完美的工作，通過收斂 Api: 所有垂直都有不同的運輸車輛，這意味著對生態系統的某些部分將總是落在後面。
更好的方法統一實現: 而不是只提供一個構造良好的看法，我們應該提供一個構造良好的實現。這將允許垂直簡單分享相同的實現。收斂將不再是額外的;它被通過建設。當然，還有一些情況下我們可能需要多個實現的地方。文件 I/O，這需要使用不同的技術，基於環境是一個很好的例子。然而，它是要問每個團隊擁有特定的組件，想想他們的 Api 跨所有縱向市場比試圖追溯提供一致的 API 堆棧頂部的工作簡單得多。這是因為可移植性不是一個什麼東西你可以稍後提供。例如，我們的文件 Api 包括支持為 Windows 訪問控制列表 (ACL)，不能在所有環境中支持。Api 的設計必須考慮這問題，和，例如，在不支持 Acl 的平台上提供此功能在一個單獨的程序集，可以省略。
另一個有趣的挑戰就是要與.NET 框架如何部署。
.NET 框架是一個機全框架。對它所做的任何更改會影響所有應用程序都以它的依賴項。有一個機器全框架是一個深思熟慮的決定，因為它解決了這些問題:
但它也是需要付出代價。
其一，它復雜應用程序開發人員對最近公布的框架采取一個依賴項。你必須帶上最新的操作系統依賴項或提供應用程序的安裝程序能夠安裝.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 核心是可以用在各種各樣的垂直縮放從觸摸基於的設備的數據中心的模塊化實現是可用作為開放源碼和支持由微軟 Windows、 Linux 和 Mac OSX 上。
讓我走進的如何.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 縱向市場。
與.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 組件用敏捷的方式:
在所有三個元素使得我們能夠提供廣泛的敏捷性和成熟。
雖然我們設計.NET 核心，它將成為未來的所有堆棧的基礎，我們非常了解創建"一個通用堆棧"，每個人都可以使用的困境:
我們相信我們找到的未來奠定了基礎，同時保持與現有堆棧大互操作性的良好平衡。我去看幾個這些平台更多的細節。
.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 商店 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 框架的平台。答案是: 它像今天一樣，你可以繼續使用便攜式類庫和共享的項目:
便攜式類庫是偉大的當你常見的代碼是獨立於平台的以及作為可重用的庫位置的特定於平台的代碼可以被分解。
共享項目是代碼的偉大，當你常見的代碼有幾位的特定於平台，因為你可以適應它與#if.
為更多細節兩者之間選擇，看看這篇博客.
在向前邁進，便攜式類庫還將支持針對.NET 核心的基礎平台。唯一的區別是，如果你只有目標.NET 核心基礎平台你不要一套固定的 API。相反，它基於的 NuGet 程序包，您可以在升級將。
如果您還不基於.NET 核心的至少一個平台，你被受到可以共享它的 Api。在此模式下，你仍然能夠升級 NuGet 程序包，但可能會提示您選擇更高的平台版本或完全放棄對他們的支持。
這種方法允許您共存在兩個世界同時也獲得了.NET 核心帶來的好處。
