本系列技术大约30篇文章，欢迎关注、点赞、评论、转发，每天都能获取IT优质内容。
微软于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 Core的主要原因有两个：
- 为跨平台.NET奠定基础作为.NET开发人员，现在可以在一段时间内不仅在Windows上构建和运行代码，还包括Linux，MacOS，iOs和Android。挑战在于Windows实现具有一个代码库，而Mono具有完全独立的代码库。Mono社区实际上被迫重新实现.NET，因为没有可用的开源实现。当然，自Rotor起就可以使用源代码，但是我们没有使用OSI批准的开放源代码许可证，这使得Rotor成为一个非启动程序。客户报告了各种不匹配的情况，很难修复，因为任何一方都不能查看另一方的代码。这也会导致在实际上并不特定于平台的领域中出现大量重复工作。最近的一个例子是不可变集合。构建跨平台堆栈的最佳方法是以协作的方式构建单个堆栈。做到这一点的最佳方法是将其开源。
- 建立并利用更强大的生态系统微软团队通过NuGet追求了一个更加敏捷的开发周期，至今已有近两年时间。我们已经看到在早期发布并经常发布以使客户提供反馈方面取得了巨大的成功。
使用 GitHub
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流程。
构建并运行自己的Forks
为了发挥我们的作用或尝试自己的修改，您需要能够构建和运行自己的库版本。我们希望使它像馅饼一样容易，所以这里是：
- 您克隆了我们的仓库（）git clone https://github.com/dotnet/corefx
- 您调用 build.cmd
该构建仅需要Visual Studio 2013（即不需要“ Dev14”）。它将构建所有库并运行单元测试。
过去我们面临的挑战之一是强大的命名，这使您无法将二进制文件简单地放入现有项目中。我们通过提供一种强名称二进制文件的新方法解决了这一问题，我们称其为开放源代码签名。您可以在我们的开发人员指南中找到更多信息。
.NET 基金会
.NET Core项目由.NET Foundation负责。我们认为，这将是促进和推进.NET Core堆栈的关键部分。我们正在与Xamarin / Mono的Miguel de Icaza紧密合作，以创建可以成为.NET Core跨平台实现的共享代码库。
如今，GitHub上只有一部分库可用：
- 不可变集合
- SIMD
- Assembly Metadata Reader
- XDocument
- XmlDocument
以下是我们正在努力的领域：
- 更多的类库。
- 在非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/
本系列技术大约30篇文章，欢迎关注、点赞、评论、转发，每天都能获取IT优质内容。
系列博客文章导航