Microsoft’s new C# compiler Roslyn has been in the pipeline for quite some time. Eric Lippert first put out a call for developers to work on Roslyn back in 2010, when we worked with C# 3.0 and built our own state machines to handle aynchronous function calls.
So it’s safe to say that Roslyn has been on the team’s mind for well over three years. Roslyn obviously marks a large investment on behalf of Microsoft. So why take the time to rearchitecture the C# and VB compilers? After all, software rewrites have typically been at the top of on the list of “Things You Should Not Do”.
Most people familiar with Roslyn understand that it marks the first real change in compilers in recent memory. For decades, compilers operated as black boxes that took source code in, and spit out binary, ByteCode or IL. Short of building your own compiler, there was no easy way to peek at the syntax tree or reason about the semantics of a codebase. Roslyn opens the compiler up, making syntactical and semantic structure available to average developers who don’t want to write a feature-complete compiler just to create a Visual Studio plugin.
So the questions surrounding Roslyn boil down to: “What can I build now, that I couldn’t before”.
Intelligent Tooling
Roslyn allows developers to reason about the code in an intelligent manner. No longer are extensions forced to deal with a codebase as a set of files containing strings. From the perspective of the extension, a C# solution is made up of pieces of syntax and structure at varying levels of granularity. Need to find all method invocations within a given document? No problem, simply crawl the syntax tree looking for all syntax of type InvocationExpressionSyntax. Need to find that method’s declaration? No problem, simply pass that InvocationExpressionSyntax to the document’s SemanticModel.
We’ve been using this exact approach to build CodeConnect, a Visual Studio extension in which users edit functions rather than files.
Roslyn allows us to quickly find all invoked functions within a given function and lay them out for a user. This kind of project would only have been possible had we built our own parser and lexer and built an internal representation of a given codebase. It would have needed to be fault tolerant and handle temporary errors as users typed their code. It would have had to waste clock cycles compiling code Visual Studio had already compiled internally.
Scripting Engine
I’m equally excited about Roslyn’s Scripting Engine, despite only having toyed with it briefly. The ability to compile, analyze and execute arbitrary code seems incredible. Already, individuals have worked to develop plugins that execute code as you’re developing, in the style of Brett Victor. While I think it’s a difficult solution to generalize, I would not be surprised if we see a feature-complete, LightTable-esque approach to this problem once individuals become more familiar with the Scripting Engine.
In short, I expect Visual Studio’s tooling to improve dramatically once Roslyn ships. Roslyn has lowered the barrier to entry when it comes to writing intelligent, useful extensions for Visual Studio. I expect we’ll see a number of exciting tools be created that dramatically change the way in which we interact with our code.
I’m looking forward to tools and plugins that go beyond simple renaming refactoring and enforcing coding standards. I’m hoping the C# community can churn out some really cool tools that change the way in which we write code altogether.
Check out http://codeconnect.io for our take on making interesting plugins for Visual Studio.
Interested in playing around with Roslyn? Learn Roslyn Now!
Shotgun Debugging 
Great write up. We’ve also used Roslyn on dotnetfiddle.net We think it is incredibly powerful as well.
“Most people familiar with Roslyn understand that it marks the first real change in compilers in recent memory. For decades, compilers operated as black boxes that took source code in, and spit out binary, ByteCode or IL. Short of building your own compiler, there was no easy way to peek at the syntax tree or reason about the semantics of a codebase.”
You mean that before this there weren’t languages which exposed their internal AST for manipulation? Surely that can’t be it since:
– Java has ejc and janino (at least)
– Python has the AST module
– Perl has B::Deparse
and some of these solutions are more than a decade old.
Or perhaps you mean that there wasn’t a solution for C#? Than can’t be it either since the Mono Cecil project has been available for almost 4 years now.
Thus I must conclude that you mean “after decades Microsoft is giving official guidance so that people of the “nobody has been fired for buying IBM” now can use something” 🙂