.NET核心开源_最新动态_新闻资讯_程序员俱乐部

中国优秀的程序员网站程序员频道CXYCLUB技术地图
热搜:
更多>>
 
您所在的位置: 程序员俱乐部 > 新闻资讯 > 最新动态 > .NET核心开源

.NET核心开源

 2014/11/17 16:07:43    程序员俱乐部  我要评论(0)
  • 摘要:英文原文:.NETCoreisOpenSource对于.NET来说,今天是个大日子!我们很高兴宣布.NET核心将要开源,包括运行时环境和框架类库。这是我们为开源努力的自然结果,我们已经开源了主要的编译器(C#,VB、F#),还有ASP.NET:C#和VB("Roslyn")VisualF#工具集ASP.NET5实体框架我们通过将范围扩展到.NET运行时环境和核心框架,使(微软开源进程)进入下一个阶段。.NET核心框架什么是.Net核心?.Net核心是一个模块化的开发栈。该开发栈包含
  • 标签:.net net 开源

微软宣布 .NET 开发环境将开源支持三大操作系统

  英文原文:.NET Core is Open Source

  对于 .NET 来说,今天是个大日子! 我们很高兴宣布.NET 核心将要开源,包括运行时环境和框架类库。

  这是我们为开源努力的自然结果,我们已经开源了主要的编译器(C#,VB、F#),还有 ASP.NET:

  1. C# 和 VB ("Roslyn")
  2. Visual F# 工具集
  3. ASP.NET 5
  4. 实体框架

  我们通过将范围扩展到 .NET 运行时环境和核心框架,使(微软开源进程)进入下一个阶段。

  • .NET 核心框架

  什么是 .Net 核心?

  .Net 核心是一个模块化的开发栈。该开发栈包含 .Net 平台的所有特性。这些特性已经被用在 ASPNET Core 5 和 NET Native。下面会详细介绍什么是 .Net 核心以及它和 NET Framework 的关系。

  为什么我们要开源 .Net 核心?

  我们开源 .Net 核心有下面两个原因:

  1. 跨平台的 .Net 奠定基础

  2. 建立一个强大的生态系统

  下面让我们来关注更多细节。

  为跨平台 .Net 奠定基础

  作为一个 .Net 开发者,你以后可以在 Linux、 MacOS、 iOs 和 Android 上构建或者运行你的程序,而不仅仅是 Windows。

  这有一个挑战就是,windows 已经有一套代码实现,同时 Mono 也有一套代码实现。Mono 社区事实上被强迫重新实现了一次 .Net,因为没有开源的代码实现。当然该代码实现可以通过 Rotor 来让变得可用。但是没有我们的开源授权,让这件事变得不可能。客户已经提出了很多的问题,但是这些问题很难去修复,因为双方都不可以看到对方的代码。这也导致了很多重复的工作,而且实际上这些工作不是针对特定于平台而导致的。immutable collections 就是一个很明显的例子

  建立一个扩平台的技术栈的最好方法,就是通过合作的方式去建立唯一的技术栈。同时最好的合作方式就是去把它开源。

  建立并利用一个强大的生态系统

  我的团队使用 NuGet(.NET 平台下一个开源项目)实现更敏捷的开发周期已近两年了。 为了让客户提供反馈,我们早期进行了发布,现在我们已取得了巨大的成功。

  如果你仔细思考会发现: 开源本质上是敏捷开发模式。 每一个改动都需要立刻发布,并且(在理论上)可用。 我团队里的很多成员是 Twitter 和 Stack Overflow 会员,他们热衷于客户讨论。 不止一次,我希望我能够给客户介绍内部文档,并向他们解释我们的系统是如何实现的。 或者只是简单地介绍一个问题是如何被解决的。

  对于我们来说,开源架构也意味着我们可以实时与客户进行交流。 当然,并不是每一个客户都想我们紧密互动。 但是确实有一些人使得架构变得更好,因为他们提供了早期、稳定的反馈。

  我把这比作驾驶一辆汽车: 频繁的小幅度的调整方向盘比大幅度的调整更有效,且风险更低。

  选择利用 GitHub

  我们决定在 Github 上存放 .Net 核心的代码,因为据 Phil Haack 说在 Githut 上发布代码,可以帮助提高效果:

  这当然是开玩笑。

  作为一个原则,我们不想告诉社区我们在哪里。相反,我们应该去到社区它本身就存在的地方。根据其他的一些项目反馈来看,Github 是 .Net 的最主要社区。

  不相信?我原来也怀疑所以我做了个小实验。我将自己的一个开源项目从 CodePlex 上移到了 GitHub 上。在 CodePlex 上两年了我只有一个 pull request,而移到 GitHub 上五天后我的 pull request 就达到了三个,而且发现了另外两个贡献者。这是三个月前了,总共从那时起我已经获得了 16 个 pull request,许多都有实质性的进展。(顺便说一句:最开始的那一个被加进了很多单元测试,很酷有木有?)尽管这个还不算是严格意义上的案例,但确实能让我们听到更多客户的需求。

  所以为了加入社区,我们决定将 .NET Core 发布在 GitHub 上,一个月前,在 GitHub 上已经能看到我们的成果了(our samples available on GitHub)。

  开源的开发经历

  我的团队也开源过,比如 MEF 项目,但平心而论,那个并没取得多少收获。我们认为基本的原因是缺少社区的参与。当我们只开放了源码后,并没有努力为之建立一个社区。我深深感到,建立一个社区才是开源项目成功的关键所在。而建立一个社区的关键是开发的过程也要开源地进行。

  为不辜负期望,我们同样也会透明我们的开发计划是什么,我们要克服的有那些挑战,以及哪些范围还未完成。我来解释一下这些。

  第一步是要停止 code bombs,就像之前 MEF 中投的那些一样。代码炸弹本质上是不定期的公开更新的源代码,它们是系统项目组内部正在完成的代码。由于各种原因,这样做是有问题的。举个例子,公布的时间延迟,大家很难看到同一份代码,这样就很难进行公开的讨论。另一个大问题是历史版本丢失,自动同步让我们同步一致代码,但感觉像 reinventing Git.

  所以为防止代码炸弹,我们建立我们的开发环境在公开的 GitHub 仓库,它是一个领先的系统。这意味着所有的代码修改会立即表现出来。但我们不会:

  • Code reviews.  我们希望所有的代码审查过程全公开,通过 GitHub’s pull request model.

  • 设计文档及讨论,我们同样共享设计时的备注、规格以及实现的文档。我们一定会讲清楚我们将用什么格式。至少让你可以记下基本文档,就像 Mad’s C# design notes 的一样。另一个想法是,我们给我们的设计讨论会录音,然后共享到 Channel 9。我们一定会讲清楚,我们会以什么样的节奏去,怎么实现它。

  我们初步计划使用 GitHub 问题清单功能来跟踪 bug。 巧妙的是我们也提供了其它途径,如 UserVoice 论坛,微软 Connect 网站和我们内部的团队协作服务器(Team Foundation Server)。 它们的介绍如下:

  • User Voice论坛。 在潜在昂贵项目排名方面,UserVoice 有优秀的投票系统。 因此,对于更大特性和根本创新,UserVoice 是搜集反馈的最佳选择。

  • 微软 Connect 网站。 Connect 网站主要用户是企业用户和产品支持人员。 我们将有可能继续使用这个网站用于产品支持,但是不推荐你使用(它来提交 bug),除非是提交 .NET 核心的 bug。

  • 内部团队协作服务器。 我们不再使用 TF Version Control 工具来管理 .NET 核心,但是仍然管理大块的 DevDiv 模块。 为了能够跨平台的协作工作,我们会继续允许团队通过 TFS 提交 bug。 我们正在考虑如何公开那些 bug。 一个方法是创建一个自动镜像系统。

  在 UserVoice 和 Connect 网站上,当我们的团队成员在 GitHub 上提交了相应的问题后,你可以看到一个关闭 UserVoice/Connect 上问题的流程。

  我们接受贡献

  是的,我们接受贡献!不过,与任何开源项目一样,我们不会盲目的接受所有的贡献。我们所收到的所有 pull 请求都会按照下面的标准进行评判:

  • 路线图(Roadmap)。所有项目都专注在某些领域。为了保持重心和发展势头,大部分工作向项目路线图看齐是很重要的。

  • 质量(Quality。我们要为输送高质量代码负责。因此,外部人员必须满足与微软员工相同的质量标准。包括正确的设计、架构、足够的测试覆盖率和遵守编码风格。

  我们相信通过为外部开发者提供足够的环境,在开源界的开发将会成功。例如,你可以看到我们的代码审查并且阅读内部是如何设计的相关文档。我们将会公布路线图。

  贡献者最好提早与我们沟通你的想法。这样的话,我们就可以给你提供一些帮助,比如提供文档或者是针对你的方案进行讨论。我们也会把我们希望大家做的工作发布在 GitHub 的 issues 列表上,供大家进行选择。

  通常,所有的社区贡献都要通过 GitHub 的 pull request 模型来完成,也就是说,你首先要 fork 我们的项目,并在你的分支上进行开发,最后通过 pull request 将代码提交到主干上。 对代码检视也同样是使用这一模型。

  在我们合入你的贡献之前,你还需要签署一份 Contributor License Agreement (CLA)协定。我们目前正在把这个工作工具化,最后的效果可能和 Azure CLA 过程类似。

  构造并运行你自己的分支

  要玩玩我们的程序或实验你自己做的更改,你需要构建并运行你自己的库版本。我们想要做的尽可能的简单,所以看这里:

  • 克隆我们得仓库(git clone https://github.com/dotnet/corefx
  • 调用 build.cmd

  只需要 Visual Studio 2013 用来构建(不用“Dev14”)。将会构建所有得库并运行单元测试。

  过去我们我们做的一个更改是强命名,以防止你草率的删除已存项目的二进制文件。通过提供强命名二进制文件的新方法我们已经解决了这个隐忧,我们把新方法叫做开源签名。你可以在我们的开发者指南中找到更多信息。

  .NET 基金会

  .NET 核心项目是由 .NET 基金会来进行管理。他将成为推动 .NET 核心栈不断向前的关键力量。我们还会与 Xamarin/Mono 项目的 Miguel de Icaza 进行紧密的合作,来创建一个共享的代码基线,使其发展为一个跨平台实现的 .NET 核心栈。

  今天,只有部分代码库可以在 GitHub 上访问到:

  Immutable Collections
  SIMD
  Assembly Metadata Reader
  XDocument
  XmlDocument

  我们会以下几个领域持续发力:

  • 更多的代码库. 目前开源的部分,可以理解为整个项目的首付款。我们的目标是在 2015 年开源整个 .NET 核心栈。
  • 构建和运行在非 Windows 平台. 我们现在只提供了在 Windows 上进行构建和运行的能力。我们正计划与 Mono 社区一起组件一个公开的工作组来完成此项工作。
  • .NET 核心运行时环境 (CoreCLR). 我们正在拟定运行时环境的开源计划。请保持关注。

  总结

  .NET 核心栈将在 GitHub 上完全开放源代码。我们已经对其中的一些库做了一些必须要进行的工程性更改,并在核心框架代码仓库中包含了它们。从现在到生成 2015 构建期间,你将看到我们在开放源代码方面所做的工作。欢迎下载源代码!

  请多多使用.NET 基金会的论坛,让我们知道你们所想!

译者:daxiang, i好人大叔 am, noonoo, 开源中国七里香, YiHunter, James_飏, 几点人7 人。来源:开源中国。

发表评论
用户名: 匿名