Intro
As a part of metaprogramming series we are going to provide a set of articles for explaining new .NET Roslyn Compiler which is the new .Net compiler platform. Roslyn is the new generation of .NET compilers for C# and VB.NET written in those languages themselves, it provides a rich ecosystem and APIs for modelling all aspects related with source code that allows us to perform a lot of actions related with code like code analysis for C# and VB.NET, we can also build and integrate in Visual Studio a collection of language services for doing tasks like refactorings, code browsing like “go to Definition” or “Find All References “and intellisense. In addition to that we can also build our own compilers and tools. Roslyn change the black-box philosophy for compilers offering a complete collection of APIs for performing all these tasks, this open up a new world of possibilities from metaprogramming point of view and this is the reason for including Roslyn in this series. In this article I´ll try to provide a general overview of Roslyn from a high level perspective; in upcoming articles we will experiment with Roslyn for showing its amazing capabilities
Reasons for Roslyn
There were multiple reasons for a new rewriting of existing C# and Vb.Net compilers, some of them are the following ones
Traditional C# and vb.net compilers were written in C++
Before Roslyn arrival, compilers for C# and VB.Net were written in C++, which makes difficult and hard creating and testing new compiler features for languages services, etc… so a productivity problem was on the table. So It´s clear that having the C# and VB.Net compilers written in C++ is not the most efficient way of evolving each language specifications. Every time you need to publish a new feature you need to involve several language-heterogeneous teams in that endeavour with the logical overexertion to preserve these new features in line. Before Roslyn arrival, try to publish new language features was a multi-team undertaking. Thanks to new Roslyn compilation model is possible to ship new language features (C# and VB.NET) in a centralized and much faster way
Different compilers for different environments
On the other hand, new needs lead to new compilers, for instance: traditional “command line” compiler is different from the one of “immediate window” which in turn is also different from the one running in background in visual studio when we are editing source code file.
So It´s a matter of fact that we can find different compilers depending on compilation environment in which we are working. For instance, we can find the csc.exe or vbc.exe batch-compilers that are especially useful when we need to compile a great number of files in the same assembly with acceptable performance and detailed error reporting. On the other hand we can find the Visual Studio background-compiler which is very responsive to user interaction and provides a collection of known languages services, this compiler only manage one file at once and is also very tolerant under incomplete codes. There exists a third compiler that is also integrated with Visual Studio: sniper-compiler, this compiler comes to play every time we use the Immediate Window from VS and only integrate a small subset of C# and vb.net characteristics. Having so many different compilation flavours is not efficient from the maintenance point of view and this is key point in which Roslyn comes to rescue, by providing one compiler code base in which every update is automatically propagated to all compiler-environments
Agile platform for prototyping new languages features
With Roslyn Microsoft consolidates a platform that allows creating, prototyping and testing new language features for C# and Vb.Net. In addition Roslyn provide a rich ecosystem of APIs for modelling all stages and artefacts related with compiler pipeline process. With these APIs in place we can make use of syntax and semantic elements with a high degree of flexibility.
In addition Roslyn provides an opened compilation model and a centralized compiler implementation which means that there is no need to replicate new language features in different compiler environments: once we have defined new language feature then this feature applies to all compilation environment. This increases the productivity and allows creating and experimenting with more tools.
Black-box philosophy vs Open Object Model for representing the code
Traditional compilers behaviour had to do with black-box philosophy: compilers usually take a collection of code-files that follow a pre-establish language specification and emit program files like dll file, exe file, etc… what happens behind the scenes is keep it closed and unreachable. Now with the new compilers generation like Roslyn a new rich compilation object model has been provided and anyone can open the specification and customize or contribute. Thanks to the richness of new compilation ecosystem, third parties can easily develop new tooling features for Visual Studio (or the editor they use) without relying on previous private compilation APIs and making easing for anyone to get knowledge about how the compiler works and contribute to Roslyn evolution
Sumary
So main reason can be summarized in the following way:
- Faster Compiler Platform for creating, prototyping and testing new language features
- Rich APIs ecosystem for modelling source code with full fidelity
- Flexible APIs for performing syntax and semantic analysis and build language services
- Centralized Development Platform (no need for different versions of compilers)
- Open Source Ecosystem
That´s all by now
See you on the road !