“我们把所有对于语言正确性和性能的要求都集中在一份代码中，使其拥有最佳的质量和最好的多样性——我们将重新定义“编译器”这个词。”

Roslyn是C#和Visual Basic.NET的开源编译器的项目名。十年来它从微软的封闭中走出来，变成现在的开源、跨平台、公开的语言引擎，支持一切使用C#的东西（包括VB，我认为它是C#带来的馈赠）。

在我2005年加入微软的时候，有过一次关于Roslyn项目的讨论，当时刚好是.NET 2.0发布前夕。那次讨论的内容是用C#重写C#。这种事情在编程语言中很常见，也是语言成熟的一个标志。但这样做还有个更现实、更重要的动机：作为C#的缔造者的我们竟然用的不是C#，而是C++！日常使用C#能改变你对C#的看法，这就是使用自家产品的好处。

客户期待新的编译器行为与旧编译器完全一致。使用C#重写编译器意味着连bug都要与旧编译器完全一致。

重写一个客户已使用多年的编译器有很多难点：新的编译器必须拥有完全一致的行为。编写新的C#编译器意味着连bug都要与旧编译器完全一致。而且这里说的还不仅仅是已知的bug，还有许多未知的bug和无意的编译器行为，由于被程序员发现并且利用（而且通常人们意识不到自己利用了这些行为），所以也必须原样实现才行。

这种级别的难度使得我们很多年来都不敢碰这个项目。

此外，尽管使用C#编写新的C#编译器可能会有很多好处，但其价值却很难展示给客户：新的编译器对现有客户有什么好处呢？也许，唯一在乎C#编译器是否用C#编写的人只有编译器团队自己了吧。

但同时，另一个问题也越来越明显，即所有使用了C#代码的工具都需要进行修改，尽管这部分工作具有重复性。除了编译器之外，我们的兄弟团队在开发Visual Studio中的C# IDE支持，他们也需要写一些代码（当时也是C++代码）来理解C#的语法和语义。

除此之外，微软和其他第三方如StyleCop、CodeRush等工具也越来越多，所有工具都要根据C#源代码文本实现。这些工具都有不同的bug，对C#的理解程度也不尽相同，也都做了不同的妥协和权衡取舍。这一切都需要越来越多的努力，只为了解决一个问题：理解源代码。

到此，我们终于能够提出项目的价值了：全世界只需要一份理解C#的代码，任何想开发代码工具的人都可以共享这份代码！

这样，客户价值就能体现在工具数量的增加，特别是现有工具的质量提高。我们把所有对于语言正确性和性能的要求都集中在一份代码中，使其拥有最佳的质量和最好的多样性。我们需要构建一个语言引擎！一个通用的、公开的C#代码API！我们将重新定义“编译器”这个词。

当然，要想为广义的C#社区开发API，很显然必须开发成.NET API，因此要用C#实现。所以，用C#自我编译C#的梦想可以作为意外收获顺带实现了。

于是，Roslyn从一个开放的思想中诞生了：将C#的内部工作共享给世界，使之可以通过程序访问。在一个无处不在封闭式文化中，这种想法是一个非常大胆的决定：我们要把知识产权无偿分享？我们要给那些不属于我们的工具开发商提供支持让他们跟我们竞争？

最后我们得出的结论是：增强生态环境，使之成为全世界最好的工具语言。这是为了C#和.NET的长期增长，而不是只为了眼前的利益和保护微软的财产。所以，就算不谈开源，考虑到成本和风险，Roslyn项目的通过对于微软也是件不容易的事儿。

当然，Roslyn项目并不是这么简单。Roslyn的愿景充满了野心，也充满了技术挑战，我们花了五年时间才实现。但这是另一个话题了。

我们花费了很多时间来构建初始版本，而此时Roslyn依然是个闭源项目。从2009年早期这个项目伊始，我们就制定了将编译器开源的愿景，但微软显然还没做好准备。私下开发再提交专利，这是微软从上世纪七十年代开始一贯如此的做法。尽管现在有所改变，但改变的速度显然比我们期待的要慢得多。

实际上，有段时间我们似乎觉得公司会完全走向相反的方向。

Windows 8项目似乎占用了整个公司的精力。随着新编程模型的出现，Windows 8的触角伸到了开发工具和语言团队中，每个人都被要求高度保密，不仅要对外部保密，而且在公司内部也要保密。比如，我们当时开发的异步功能需要协调Windows 8的编程模型，因此我甚至都不敢在内部发表设计上的说明，以免不小心泄露Windows 8的消息给自己带来麻烦！这种氛围非常不利于创新，当然对于我们希望让C#编译器开源也不是好兆头。

但最终，在Windows 8完成开发之后，公司开始转变到新的方向上，新的领导团队带来了完全不同的价值观，即我们今天的微软。开源活动像雨后春笋般在微软内部生根发芽。

F#于2010年以开源授权发布，并且成立了自己的基金会——F#软件基金会（https://fsharp.org/）。在它周围迅速成长起来的生机勃勃的社区得到了我们所有人的嫉妒。我们的团队继续努力推行Roslyn的开源产品授权，最后终于实现了。

2012年，微软建立了微软开源技术——一个专门关注开源项目的组织。Roslyn移交给了微软开源技术，从而正式成为开源项目。Roslyn非常适合开源：所有开发资源都属于内部并且广为人知，项目自身也没有太多可能造成授权冲突的依赖。

2014年4月，在旧金山召开的微软“Build”开发者大会上，Anders Hejlsberg第一次展示了作为开源项目的Roslyn（https://blogs.msdn.microsoft.com/csharpfaq/2014/04/03/taking-a-tour-of-roslyn/），随后Roslyn于4月3日在 CodePlex（微软后来退役了的开源代码平台）上以Apache 2.0的授权发布了。

微软开源技术组织下CodePlex上的Roslyn项目

同时，公司还宣布.NET基金会成为包括Roslyn在内的.NET项目的总部。

成为开源给我们带来了美好的新鲜空气！在我们开始尽情享受CodePlex的开放时，微软的其他开源过程也已做好准备，而现在，开源已经深入人心，许多团队都在使用开源。

GitHub不仅是我们发布代码的地方，也是我们日常工作的场所。

此外，公司还意识到，我们不需要控制一切。很明显，CodePlex没有存在的理由，因此Roslyn同其他项目一起从CodePlex移动到了GitHub，当时GitHub已经成为开源项目事实上的家园。这样，不仅代码托管在GitHub上，而且整个构建过程都放在了GitHub上。GitHub不仅是我们发布代码的地方，也是我们日常工作的场所。

现在Roslyn放在了GitHub上

C#语言的设计和编译器的实现现在完全开源，有许多微软之外的人参加，其中还包含许多完全由外部贡献者构建的语言功能。这对C#有极高的价值，其中不仅有实现功能和修复bug的贡献，通过开源提供的日常反馈，我们还能获得及时的灵感和洞察。

这段旅程漫长又艰苦，而在我看来值得一提的是：微软在过去十年内做出的巨大改变。Roslyn诞生于封闭，成长于开放，直到今天借助开源之力在几百万用户间绽放。

来亲眼看看Roslyn和C#的语言设计吧：

• https://github.com/dotnet/roslyn

• https://github.com/dotnet/csharplang

原文：https://medium.com/microsoft-open-source-stories/how-microsoft-rewrote-its-c-compiler-in-c-and-made-it-open-source-4ebed5646f98

作者：Mads Torgerson，微软的C#首席架构师。

译者：弯月，责编：郭芮