微軟於2014年11月推出了.NET Core 1.0。.NET Core的目標是從我們在過去12年中對.NET Framework的構建、交付和服務的經驗中吸取教訓，並開發出的更好的產品。這些改進的一些例子包括並行安裝（可以安裝新版本，而不必擔心破壞現有應用程序）、自包含應用程序（應用程序可以嵌入.NET，因此.NET不需要在計算機上安裝），而不是Windows操作系統的一個組件（.NET發布獨立於操作系統時間表的新版本）等等。在此基礎上，我們使.NET Core開源和跨平台。
.NET Core 1.0主要關注高性能Web和微服務。NETCore2.0增加了2000多個API和組件，如Razor頁面和SignalR，使Web應用程序更容易移植到.NETCore。現在.NETCore3.0通過添加WinForms、WPF和EntityFramework6來支持桌面應用程序，這使得將桌面應用程序移植到.NETCore成為可能。
在.NET Core 3.0之后，我們將不再從.NETFramework移植更多功能。如果您是一名Web Form開發人員，並且希望在.NET Core上構建一個新的應用程序，我們建議您使用Blazor，它提供了最接近的編程模型。如果您是遠程處理或WCF服務器開發人員，並且希望在.NET Core上構建新的應用程序，我們建議您選擇ASP.NET Core Web API或gRPC，后者提供跨平台和跨編程語言（基於契約的gRPC）的能力。如果您是Windows工作流開發人員，則有一個.NET Core的開源工作流項目。
隨着.NET Core 3.0於2019年9月發布，我們認為所有新的.NET應用程序都應該基於.NET Core。.NET Framework 中支持的主要應用程序類型在.NET Core 中任然受到支持。如果某些組件沒有被移植過來，則建議使用新的技術替代（如：gRPC代替WCF、Workflow-Core 與 elsa.NET 代替 WorkFlow）。在.NET中的所有未來投資都將在.NET核心中進行。這包括：運行時、JIT、AOT、GC、BCL（基類庫）、C#、VB.NET、F#、ASP.NET、實體框架、ML.NET、WinForms、WPF和Xamarin。
.NET Framework 4.8 將是.NET Framework的最后一個主要版本。如果您有您正在維護的現有.NET Framework應用程序，則無需將這些應用程序移動到.NET Core。我們將繼續服務和支持.NET框架，其中包括bug、可靠性和安全修復。它將繼續隨Windows一起發布（大部分Windows依賴.NET Framework），我們將繼續改進Visual Studio中對.NET的工具支持（Visual Studio是在.NET Framework上編寫的）。
新的應用程序應該建立在.NET Core上。.NETCore是.NET未來投資的地方。現有的應用程序可以安全地保留在.NET Framework上，這將得到支持。想要利用.NET新功能的現有應用程序應該考慮遷移到.NET核心。隨着我們對未來的規划，我們將為平台帶來更多的功能。
.NET Core是一個模塊化的開發堆棧，是將來所有.NET平台的基礎。ASP.NET5和.NET Native已經使用了它。下圖展示了NET Core以及它與NET Framework的關系。
開源.NET Core的主要原因有兩個：
- 為跨平台.NET奠定基礎
- 作為.NET開發人員，現在可以在一段時間內不僅在Windows上構建和運行代碼，還包括Linux，MacOS，iOs和Android。挑戰在於Windows實現具有一個代碼庫，而Mono具有完全獨立的代碼庫。Mono社區實際上被迫重新實現.NET，因為沒有可用的開源實現。當然，自Rotor起就可以使用源代碼，但是我們沒有使用OSI批准的開放源代碼許可證，這使得Rotor成為一個非啟動程序。客戶報告了各種不匹配的情況，很難修復，因為任何一方都不能查看另一方的代碼。這也會導致在實際上並不特定於平台的領域中出現大量重復工作。最近的一個例子是不可變集合。
- 構建跨平台堆棧的最佳方法是以協作的方式構建單個堆棧。做到這一點的最佳方法是將其開源。
- 建立並利用更強大的生態系統
- 微軟團隊通過NuGet追求了一個更加敏捷的開發周期，至今已有近兩年時間。我們已經看到在早期發布並經常發布以使客戶提供反饋方面取得了巨大的成功。
2018年6月微軟以75億美元收購 GitHub。之后.NET團隊決定在GitHub上托管.NET Core。原則上，我們不想讓社區來到我們這里。相反，我們想去社區已經存在的地方。根據許多其他項目收到的反饋，似乎.NET社區中的大多數人都在GitHub上。
難以置信，我也很懷疑，所以我做了一個小實驗。我把我的一個個人開源項目從CodePlex搬到了GitHub。在CodePlex的兩年里，我只收到一個pull請求。在我搬到GitHub的五天后，我已經收到了三個pull請求，並找到了另外兩個貢獻者。這是三個月前的事了。從那以后，我總共收到了16個pull請求，其中許多請求都有大量的特性工作(順便說一下：第一個是關於增加單元測試的，這有多棒？）。雖然這顯然不是一個具有代表性的樣本大小，但它確實非常符合我們從客戶那里聽到的。
所以為了達到社區的目的，我們決定在GitHub上托管.NET Core 。一個月前，我們已經在GitHub上提供了示例。
我的團隊以前做過開源，例如MEF，但我認為公平地說，這並不是很有成效。我們認為主要原因是缺乏社區參與。雖然我們提供了源代碼，但我們還沒有投資建立一個圍繞它的社區。我們堅信建立一個社區是任何開源項目成功的關鍵。為了建立一個社區，發展必須在開放的環境中進行。
為了達到期望，我們還希望在公開計划開發方式，必須克服的挑戰以及尚未完全解決的領域方面保持透明。因此，讓我解釋一下。
第一步是我們將停止做代碼炸彈，這是我們以前用MEF做的。代碼炸彈本質上是團隊實際工作的內部系統對公共源代碼的半定期更新。這個問題有幾個原因。一方面，時間延遲使公開討論變得困難，因為並非所有各方都看到同一個來源。另一個大問題是，內部歷史剛剛丟失。自動同步在某種程度上是有幫助的，但感覺就像是重新發明了Git。因此，我們沒有使用代碼炸彈，而是設置了開發環境，使公共GitHub存儲庫成為主導系統。這意味着所有代碼更改都將立即生效。但我們不會就此止步：
- 代碼審查。我們還希望通過GitHub的pull request模型讓團隊也在公開場合進行所有代碼審查。
- 設計論文和討論。我們還將共享設計說明，規范和特定於實現的文檔。我們需要弄清楚我們將使用哪種格式。至少您可以期待基於Markdown的文檔，類似於Mad的C＃設計說明。我們的另一個想法是記錄我們的設計會議並在Channel 9上分享。我們需要弄清楚如何才能以一定的節奏進行此操作。
我們計划主要使用GitHub問題來跟蹤錯誤。棘手的是，我們還有其他的來源，特別是用戶語音、連接和內部TFS。我們對這項工作的看法如下：
- 用戶語音。由於出色的投票系統，User Voice非常適合優先考慮可能相當昂貴的工作項目的投資。因此，對於更大的功能和根本的創新，用戶語音是最佳選擇。
- 連接。Connect主要供企業客戶和產品支持使用。我們很可能會繼續在該通道中使用它，但是在為.NET Core提交錯誤時，我們不建議您這樣做。
- 內部TFS。雖然我們不再將TF版本控制用於.NET Core，但大塊的DevDiv仍然可以使用。為了進行跨小組的協作，我們可能會繼續允許團隊在TFS中向我們提交錯誤。我們正在努力弄清楚如何將這些錯誤公開。一種選擇是創建一個自動鏡像系統。
我們接受貢獻！但正如任何開源項目一樣，我們並不是盲目地接受一切。我們收到的拉取請求將根據以下標准進行判斷：
- 線路圖。所有項目都將精力集中在某些領域。為了保持焦點和動力，將大部分工作與產品路線圖保持一致很重要。
- 質量。我們有責任提供高質量的代碼。因此，外部人員必須滿足Microsoft員工必須滿足的相同質量要求。這包括具有正確的設計，體系結構，足夠的測試范圍以及遵循編碼風格。
我們相信，通過公開進行開發，我們可以為外部開發人員提供足夠的成功環境。例如，您將能夠查看我們的代碼審查並閱讀有關內部設計方式的文檔。我們還將發布路線圖。通常情況下，最好通過提前告訴我們您想貢獻什么來避免過晚的意外。例如，我們可以通過向您提供指向文檔的指針或討論您的方法來提供幫助。我們還想到了將GitHub問題標記為待辦事項，以便在宣傳中表明我們希望您在特定工作項上提供幫助。
通常，所有貢獻都將使用GitHub的pull request模型完成。也就是說，您將分叉我們的項目，在主題分支中執行工作，然后針對我們的master分支提交拉取請求。這與我們用於代碼審查的模型相同。
在我們將您的工作整合到項目中之前，您需要簽署貢獻者許可協議（CLA）。我們目前正在使用該工具，但它看起來可能類似於Azure CLA流程。
為了發揮我們的作用或嘗試自己的修改，您需要能夠構建和運行自己的庫版本。我們希望使它像餡餅一樣容易，所以這里是：
- 您克隆了我們的倉庫（）
git clone https://github.com/dotnet/corefx - 您調用
build.cmd
該構建僅需要Visual Studio 2013（即不需要“ Dev14”）。它將構建所有庫並運行單元測試。
過去我們面臨的挑戰之一是強大的命名，這使您無法將二進制文件簡單地放入現有項目中。我們通過提供一種強名稱二進制文件的新方法解決了這一問題，我們稱其為開放源代碼簽名。您可以在我們的開發人員指南中找到更多信息。
.NET Core項目由.NET Foundation負責。我們認為，這將是促進和推進.NET Core堆棧的關鍵部分。我們正在與Xamarin / Mono的Miguel de Icaza緊密合作，以創建可以成為.NET Core跨平台實現的共享代碼庫。
如今，GitHub上只有一部分庫可用：
以下是我們正在努力的領域：
-
更多的類庫。
-
在非Windows平台上構建和運行。
-
.NET Core運行時（CoreCLR）。
參考文獻：
- 《.NET Core is the Future of .NET 》https://devblogs.microsoft.com/dotnet/net-core-is-the-future-of-net/
- 《.NET Core is Open Source》https://devblogs.microsoft.com/dotnet/net-core-is-open-source/