微软于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上只有一部分库可用:

以下是我们正在努力的领域:

  • 更多的类库。

  • 在非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/

.NET平台系列12 .NET未来之开源.NET Core的更多相关文章

  1. .NET6 平台系列4 .NET开源之路

    系列目录     [已更新最新开发文章,点击查看详细] .NET平台是微软于2000年推出的Windows操作系统的应用软件开发框架,发展至今形成巨大的技术栈,涉及多语言(支持C#.F#.VB.NET ...

  2. Caffe学习系列(12):训练和测试自己的图片--linux平台

    Caffe学习系列(12):训练和测试自己的图片   学习caffe的目的,不是简单的做几个练习,最终还是要用到自己的实际项目或科研中.因此,本文介绍一下,从自己的原始图片到lmdb数据,再到训练和测 ...

  3. .NET平台系列5 .NET Core 简介

    系列目录     [已更新最新开发文章,点击查看详细] 自1995年互联网战略日以来最雄心勃勃的事业 -- 微软.NET战略, 2000年6月30日. 微软公司于2002年2月13日正式推出第一代.N ...

  4. APU平台DirectX 12性能测试:超级大惊喜!

    APU平台DirectX 12性能测试:超级大惊喜! 转自:http://www.ithome.com/html/digi/129840.htm [size=1pc]微软将会在接下来的GDC 2015 ...

  5. .NET 平台系列6 .NET Core 发展历程

    系列目录     [已更新最新开发文章,点击查看详细] 在我的上一篇博客<.NET平台系列5 .NET Core 简介>中主要介绍了.NETCore的基本情况,主要包括.NET跨平台的缘由 ...

  6. .NET平台系列22:.NET Core/.NET5/.NET6 对比 .NET Framework

    系列目录     [已更新最新开发文章,点击查看详细] 在我的博客<.NET平台系列2 .NET Framework 框架详解>与 <.NET平台系列7 .NET Core 体系结构 ...

  7. 我发起了一个 .Net 平台上的 产生式编程 开源项目 GP.Net

    大家好 , 我发起了一个 .Net 平台上的 产生式编程 开源项目 GP.Net . 我们可以先看看一个网友的 代码生成器 项目 : <.Net 代码生成器 for PostgreSql> ...

  8. .NET平台系列目录

    本系列主要讲解微软.NET平台发展历程以及.NET框架技术.包含.NET Framework..NET Core.Xamarin..NET Standrad等技术与应用. 1..NET平台系列 .NE ...

  9. Java 集合系列 12 TreeMap

    java 集合系列目录: Java 集合系列 01 总体框架 Java 集合系列 02 Collection架构 Java 集合系列 03 ArrayList详细介绍(源码解析)和使用示例 Java ...

随机推荐

  1. Ambassador-08-跨域

    官方文档:https://www.getambassador.io/docs/latest/topics/using/cors/ Cross-Origin Resource Sharing-CORS ...

  2. 在Linux CentOS上搭建Jmeter压测环境

    本文的主要内容是介绍如何在Linux CentOS 服务器上面搭建Jmeter的压测环境整个详细的流程,来满足我们日常工作中对于压力测试环境搭建.压力测试执行过程的需求. 一.首先我们要准备四个东西, ...

  3. kubectl简介

    kubectl简介 kubectl是操作k8s集群的命令行工具,安装在k8s的master节点,kubectl在$HOME/.kube目录中查找一个名为config的文件, 你可以通过设置Kubeco ...

  4. 模拟退火算法(1)Python 实现

    1.模拟退火算法 模拟退火算法借鉴了统计物理学的思想,是一种简单.通用的启发式优化算法,并在理论上具有概率性全局优化性能,因而在科研和工程中得到了广泛的应用. 退火是金属从熔融状态缓慢冷却.最终达到能 ...

  5. 浅谈Java的反射机制和作用

    浅谈Java的反射机制和作用 作者:Java大师 欢迎转载,转载请注明出处 很多刚学Java反射的同学可能对反射技术一头雾水,为什么要学习反射,学习反射有什么作用,不用反射,通过new也能创建用户对象 ...

  6. 百度API定位根据经度、维度 返回当前详细地址

    百度地图API是一套为开发者免费提供的基于 百度地图的应用程序接口,包括JavaScript.iOS.Andriod.静态地图.Web服务等多种版本,提供基本地图.位置搜索.周边搜索等. 1 < ...

  7. 记一次“愉快”的lnmp环境的搭建

    愉快的lnmp环境搭建 后续更新 几个笔记记录 yum remove php-mysql yum -y install cmake autoconf wget gcc-c++ gcc zlib pcr ...

  8. CentOS7用yum安装软件提示 cannot find a valid baseurl for repobase7x86_64

    解决办法[亲测有效] 1.打开 vi /etc/sysconfig/network-scripts/ifcfg-enp4s0(每个机子都可能不一样,但格式会是"ifcfg-e..." ...

  9. 【JDK8】Java8 Stream流API常用操作

    Java版本现在已经发布到JDK13了,目前公司还是用的JDK8,还是有必要了解一些JDK8的新特性的,例如优雅判空的Optional类,操作集合的Stream流,函数式编程等等;这里就按操作例举一些 ...

  10. 从苏宁电器到卡巴斯基第12篇:我在苏宁电器当营业员 IV

    卖iPhone首先是需要接受培训的 像iPhone这样的重点产品,并不是只要选好了人(营业员),说卖就能卖的,在正式销售之前需要接受厂家的培训.如果说人事关系或者产品源隶属于苹果,那么是由苹果中国公司 ...