微软是如何使用 C# 重写 C# 编译器并将其开源的

Roslyn 是 C# 和 Visual Basic.NET 开源编译器的代号。这篇文章将介绍它是如何从微软过去的十年至暗时刻走出来，成为开源跨平台的 C# 和 VB 公共语言引擎。

我于 2005 年加入微软，也就是在.NET 2.0 发布之前，当时微软内部已经开始在讨论 Roslyn 项目，这个项目是关于使用 C# 重写 C# 编译器。这对于一门编程语言来说是一件很正常的事情，证明语言已经开始成熟。但我们的动机则更为实际：作为 C# 的创建者，我们并没有使用 C# 编程，而是用 C++！

要重写一个用户已经使用了好几年的编译器，关键问题在于用户会希望新编译器的行为方式与旧编译器完全相同。为 C# 开发新的编译器意味着需要匹配旧编译器的缺陷。我说的不只是已知的缺陷，也包括那些未知的缺陷，以及开发人员已经发现并严重依赖的无意识行为，这些通常是在不知情的情况下发生的。

多年来，这些挑战导致我们无法开始这个项目。

虽然使用 C# 编写新的 C# 编译器会给语言团队本身带来很多好处，但这样能给用户也带来价值吗？新编译器如何给现有的用户带来帮助？也许唯一关心是否使用 C# 编写 C# 编译器的人就是编译器开发团队本身。

但与此同时，我们面临着另一个越来越严重的问题：基于 C# 的不同工具之间的存在大量的重复性工作。除了编译器，我们的姐妹团队在为 Visual Studio 提供 C# IDE 支持，他们必须通过编写大量的代码（他们当时主要也是在用 C++）来理解 C# 的语法和语义。

除此之外，还有很多来自微软和其他公司的工具，如 StyleCop、CodeRush，等等。这些工具都需要实现与 C# 源代码文本相关且对用户来说有意义的功能，并且都存在一些微妙的错误。它们对一些概念的理解处于不同的水平上，而且需要做出不同的折中和权衡。所有人都需要花费大量的精力来理解代码。

最后，我们提出了我们的价值主张：我们只需要一个 C# 代码库，并把它共享给任何一个想要基于代码库构建工具的人！可用工具的增加将给用户带来价值，特别是现有工具质量的提升。我们将语言正确性和性能方面的需求集中在同一个代码库上，并努力提升质量以及添加大量的功能。我们将会构建出一个语言引擎！这将为 C# 代码提供统一的公共 API：我们将重新定义“编译器”的含义。

当然，既然你在为 C# 社区构建 API，它就应该是使用 C# 实现的.NET API。因此，使用 C#“引导”C# 的老想法借助这个机会得到了实现。

可以说，Roslyn 的诞生就是始于这种开放的心态：向世界开放 C# 语言的内部开发工作。在微软的封闭文化中，这本身就是一个大胆的主张：我们会免费分享这个知识产权吗？我们会助力那些工具开发商更好地与我们展开竞争吗？

我们希望增强生态系统并成为世界上最好的工具语言的想法最终赢得了胜利。我们想要的是 C# 和.NET 的长期增长，而不是为了短期变现和保护微软资产。因此，虽然说不上是开源，承担 Roslyn 项目的成本和风险对于微软来说也是一个重大的抉择。

当然，你不一定只是构建这些东西。Roslyn 有着雄心勃勃的愿景，充满了技术挑战，我们花了五年时间才实现。

在我们构建初始版本时，Roslyn 仍然是一个闭源项目。从 2009 年项目启动以来，我们一直希望我们的编译器是开源的，但微软还没有为开源做好准备。开发私有代码并提交专利的文化代表了微软自 20 世纪 70 年代以来的工作方式——虽然变革已经在悄然发生，但速度比我们团队所希望的要慢。

事实上，曾经有一段时间，我们感觉公司正朝着完全相反的方向发展。

Windows 8 项目几乎占据了整个公司的资源。因为采用了新的编程模型，其触角已经触及到开发者工具和语言团队的内部，所有的东西都被极端地保护起来，而且不仅仅针对外部，甚至也针对公司内部。例如，我们当时开发的异步功能融合到 Windows 8 的编程模型中，我甚至不敢在内部发表设计说明，因为担心会意外泄漏有关 Windows 8 的信息让自己陷入麻烦之中！这给创新造成了一个糟糕的环境，对于我们开放 C# 编译器的愿望来说，这当然不是什么好兆头。

最终，在 Windows 8 步入正轨之后，微软开始转型并找到了新的方向。它的核心理念变得与原来完全不一样了，也就是我们今天所知道的微软。开源运动现在开始在微软内部占据一席之地。

F# 已于 2010 年发布，基于开源许可，并提供了自己的基础——F# Software Foundation。围绕它而成长起来的一个充满活力的社区让我们所有人都感到羡慕。我们的团队强烈要求为 Roslyn 提供开源许可，最后，在公司范围的出现了一个致力于实现这一目标的基础设施。

2012 年，微软成立了 Microsoft Open Tech，一个专门关注开源项目的组织。Roslyn 转到了 Microsoft Open Tech 之下，并正式成为开源软件。Roslyn 是一个非常适合开源的候选项目：开发者都是内部有名的开发者，而且项目本身很独立，没有太多的依赖，不太有可能造成许可冲突。

2014 年 4 月，在旧金山举行的微软“Build”开发者大会上，Anders Hejlsberg 将 Roslyn 作为开源项目进行展示，并于 4 月 3 日基于 Apache 2.0 许可发布在了 CodePlex（微软之前的开源托管平台）上。

rauquam.png!web

与此同时，.NET Foundation 成为包括 Roslyn 在内的.NET 项目的家。

开放为微软带来了是一股清新的空气！在我们开始从 CodePlex 的开放性中获得好处的同时，微软也理顺了其余的开源障碍。今天，开源已经成为我们团队工作的一个直接且不可或缺的部分。

此外，在其他方面，微软意识到我们不需要控制一切。很明显，我们可能不需要 CodePlex 了，Roslyn 加入到了从 CodePlex 迁移到 GitHub 的项目行列，GitHub 是当时事实上的开源之家。不仅仅是源代码，就连构建过程都搬到了 GitHub 上：它不只是个发布代码的地方，我们把它当成工作的地方。

YFfAfab.png!web