今天是.NET的大日子！我们很高兴地宣布.NETCore将开源，包括运行时环境和框架类库。这是我们开源努力的自然结果，我们开源了主要编译器（C#、VB、F#）和ASP.NET：C#和VB（“Roslyn”）VisualF#工具集ASP.NET5实体框架我们'通过将范围扩展到.NET运行时环境和核心框架，将（Microsoft的开源进程）提升到一个新的水平。.NETCoreFramework什么是.NetCore？.NetCore是一个模块化的开发堆栈。开发堆栈包括.Net平台的所有功能。这些特性已经在ASPNETCore5和NETNative中使用。下面将详细介绍什么是.NetCore以及它与.NETFramework的关系。我们为什么要开源.NetCore？我们开源.Netcore有以下两个原因：1.为.Net跨平台打下基础2.建立强大的生态系统让我们关注更多细节。为跨平台.Net奠定基础作为.Net开发人员，您以后可以在Linux、MacOS、iOs和Android上构建或运行您的程序，而不仅仅是Windows。这里的一个挑战是windows已经有一套代码实现，Mono也有一套代码实现。Mono社区实际上被迫重新实现.Net，因为没有开源代码实现。当然可以通过Rotor提供代码实现。但如果没有我们的开源许可，那是不可能的。客户提出了很多问题，但是这些问题很难解决，因为双方都看不到对方的代码。它还导致了很多实际上并非特定于平台的重复工作。不可变集合就是一个明显的例子。构建平台扩展技术栈的最佳方式是通过合作构建独特的技术栈。同时，最好的合作方式就是开源。构建和利用强大的生态系统我的团队近两年来一直在使用NuGet（.NET平台的下一个开源项目）来实现更敏捷的开发周期。我们做了一个早期版本来获得客户的反馈，我们取得了巨大的成功。如果您考虑一下：开源本质上是敏捷开发。每个更改都需要立即发布并且（理论上）可用。我团队中的许多成员都是Twitter和StackOverflow的成员，他们热爱客户讨论。不止一次，我希望我能引导客户浏览内部文档并向他们解释我们的系统是如何工作的。或者简单地描述问题是如何解决的。对我们来说，开源架构还意味着我们可以与客户实时沟通。当然，并不是每个客户都希望我们密切互动。但有些人确实让架构变得更好，因为他们提供了早期、稳定的反馈。我把这比作开车：频繁的小方向盘调整比大调整更有效且风险更小。选择使用GitHub我们决定将.Net核心代码托管在Github上，因为根据PhilHaack的说法，在Githut上发布代码有助于提高结果：这当然是个玩笑。作为原则，我们不想告诉社区我们在哪里。相反，我们应该去社区本身存在的地方。根据其他一些项目的反馈，Github是.Net的主要社区。不相信？我也很怀疑，所以我做了一个小实验。我将我的一个开源项目从CodePlex转移到了GitHub。在CodePlex工作两年后，我只有一个拉取请求，而在转到GitHub五天后，我收到了三个拉取请求，并找到了另外两个贡献者。这是三个月前的事了，从那以后我总共收到了16个pullrequest，其中很多都取得了实质性进展。（顺便说一句：原来的那个增加了很多单元测试，很酷吗？）虽然这不是严格意义上的案例研究，但它确实让我们听到了更多关于客户需求的信息。所以为了加入社区，我们决定在GitHub上发布.NETCore。一个月前，我们已经可以在GitHub上看到我们的结果（我们的示例在GitHub上可用）。我的团队有开源开发经验，比如MEF项目，但平心而论，那个项目并没有带来多少回报。我们认为根本原因是缺乏社区参与。当我们只开源它时，没有努力为它建立一个社区。我深深地感受到，构建社区是一个开源项目成功的关键。构建社区的关键是开发过程也要开源。为了不负众望，我们也将公开我们的发展计划、需要克服的挑战以及尚未完成的领域。让我解释一下这些。第一步是停止代码炸弹，就像之前在MEF中投放的那样。代码炸弹本质上是系统项目团队正在完成的不定期公开更新的源代码。由于各种原因，这样做是有问题的。比如发布时间延迟，大家很难看到相同的代码，很难进行公开讨论。另一个大问题是历史版本的丢失。自动同步可以让我们同步一致的代码，但感觉就像是在重新发明Git。所以为了防止代码炸弹，我们在公共的GitHub存储库中构建我们的开发环境，这是一个领先的系统。这意味着所有代码修改都会立即反映出来。但我们不会：代码审查。我们希望通过GitHub的pullrequest模型，所有代码审查过程都是完全开放的。设计文档和讨论，我们还共享设计说明、规范和实施文档。我们一定会明确说明我们将使用什么格式。至少可以让您记下基本文档，例如Mad的C#设计说明。另一个想法是我们记录我们的设计过程并在第9频道分享。我们一定会说清楚我们将采用什么样的节奏以及如何实现它。我们最初计划使用GitHub问题列表功能来跟踪错误。巧妙的是，我们还提供了其他渠道，例如UserVoice论坛、MicrosoftConnect网站和我们的内部团队协作服务器(TeamFoundationServer)。它们在此处描述：用户语音论坛。UserVoice有一个优秀的投票系统，用于对可能昂贵的项目进行排名。因此，对于更大的功能和基础创新，UserVoice是收集反馈的最佳选择。微软连接网站。Connect网站的主要用户是企业用户和产品支持人员。我们可能会继续使用此网站提供产品支持，但不建议您使用它（提交错误），.NETCore错误除外。内部团队协作服务器。我们不再使用TF版本控制工具来管理.NETCore，但仍然管理大块的DevDiv模块。为了能够跨平台协同工作，我们将继续允许团队通过TFS提交错误。我们正在考虑如何暴露这些错误。一种方法是创建一个自动镜像系统。在UserVoice和Connect站点上，您可以看到在我们的团队成员在GitHub上提交相应问题后，关闭UserVoice/Connect上的问题的流程。我们接受捐款是的，我们接受捐款！然而，与任何开源项目一样，我们不会盲目接受所有贡献。我们收到的所有拉取请求将根据以下标准进行判断：路线图。所有项目都专注于特定领域。为了保持专注和势头，重要的是大部分工作都与项目路线图保持一致。质量。我们负责交付高质量的代码。因此，外部人员必须符合与Microsoft员工相同的质量标准。包括适当的设计、架构、足够的测试覆盖率和遵守编码风格。我们相信，通过为外部开发人员提供适当的环境，开源世界的开发将会成功。例如，您可以查看我们的代码审查并阅读有关内部结构设计的相关文档。我们将发布路线图。贡献者最好尽早将您的想法传达给我们。通过这种方式，我们可以为您提供一些帮助，例如提供文档或讨论您的解决方案。我们也会把希望大家做的工作发布在GitHub问题列表上，供大家选择。通常，所有的社区贡献都是通过GitHub的pullrequest模型来完成的，也就是说，你首先要fork我们的项目，在你的分支上开发，最后通过pullrequest将代码提交到主干。相同的模型用于代码检查。在我们合并您的贡献之前，您还需要签署贡献者许可协议(CLA)。我们目前正在工具化这项工作，最终的效果可能类似于AzureCLA流程。构建并运行您自己的分支要使用我们的程序或试验您自己所做的更改，您需要构建并运行您自己的库版本。我们想让它尽可能简单，所以这里是：克隆我们的存储库(gitclonehttps://github.com/dotnet/corefx)调用build.cmd只需要VisualStudio2013来构建（没有“Dev14”）.将构建所有库并运行单元测试。我们过去所做的更改之一是强命名，以防止您不小心删除现有项目的二进制文件。我们通过提供一种强命名二进制文件的新方法解决了这个问题，我们称之为开源签名。您可以在我们的开发人员指南中找到更多信息。.NETFoundation.NETCore项目由.NETFoundation管理。他将成为推动.NETCore堆栈向前发展的关键力量。我们还将与Xamarin/Mono项目的MigueldeIcaza密切合作，创建一个共享代码库，该代码库将演变成.NETCore堆栈的跨平台实现。今天，GitHub上只能访问部分代码库：ImmutableCollectionsSIMDAssemblyMetadataReaderXDocumentXmlDocument我们将在以下方面继续努力：更多代码库。目前开源的部分可以理解为整个项目的首付。我们的目标是在2015年开源整个.NETCore堆栈。在非Windows平台上构建和运行。我们目前只提供在Windows上构建和运行的能力。我们正计划与Mono社区组成一个开放的工作组来完成这项工作。.NET核心运行时环境(CoreCLR)。我们计划开源运行时环境。敬请期待。总结.NETCore堆栈将在GitHub上完全开源。我们对其中一些库进行了必要的工程更改，并将它们包含在核心框架代码存储库中。从现在到Build2015版本，您将看到我们在开源方面所做的工作。欢迎下载源码！请经常使用.NETFoundation论坛，让我们知道您的想法！
