Code Focused

10 Questions, 10 Answers on Roslyn

10 questions and answers to help understand the Roslyn complier-as-a-service project for Visual Basic and C# developers.

• By Joe Kunk
• 03/20/2012

The Roslyn Community Technology Preview (CTP) was released in October 2011. To help understand the significance and the promise of the Roslyn project, I've prepared a series of questions and answers. The questions are my own and the answers are based on my experience using the Roslyn CTP, along with my own research; but you can have confidence in the answers, as they've been reviewed for accuracy by Dustin Campbell and Kevin Pilch-Bisson of Microsoft's Roslyn team.

Roslyn is a CTP and there are many unfinished areas; it's not yet language complete. As a CTP, Roslyn includes features in C# that aren't yet available in Visual Basic, such as the C# interactive window, the C# scripting engine and the C# script code file format (.csx). That said, Roslyn is being developed under the principle of language co-evolution, so any feature seen in either C# or Visual Basic can be expected to be present in the other when Roslyn is released.

1. What is Roslyn?
Roslyn has been in development for several years at Microsoft. Roslyn is the project to fully rewrite the Visual Basic and C# compilers and language services (i.e. the language editing experiences) in their own respective managed code language; Visual Basic is being rewritten in Visual Basic and C# is being rewritten in C#.

Roslyn exposes information regarding source code parsing (what elements are present in code), semantic analysis (what they mean), binding (how they relate to each other), and IL emitting (executable code). The Visual Studio templates available for both Visual Basic and C# installed with the CTP are Console Application, Code Issue, Code Refactoring, Completion Provider and Outliner.

2. Wasn't Visual Studio already rewritten for Visual Studio 2010?
The Visual Studio 2010 editor was re-written to use Windows Presentation Foundation (WPF), but the editor still interacts with the original underlying Visual Basic and C# language services written in C++. The editor doesn't directly call the native compilers.

3. Will the Roslyn compilers perform faster than the Visual Studio 2010 compilers?
It's too soon to know, but compiler performance has been a focus for Roslyn from the beginning and is being monitored as development continues. The current native compilers are already amazingly fast, considering the myriad tasks that they must accomplish to compile a C# or Visual Basic solution.

Both the native compilers and the Roslyn compilers are primarily single-threaded, but the higher-level pieces of Roslyn, such as the language services, take advantage of the Task Parallel Library (TPL) for multi-threading when calling the compiler APIs. For example, Visual Basic and C# methods are essentially standalone once parsed and can be compiled in parallel under Roslyn.

Another opportunity for performance improvement is to retain the symbol table and other information between compilations. Visual Studio and ASP.NET both invoke the command-line compiler when building a Visual Basic or C# solution. All compiler-specific knowledge is essentially thrown away after each compile and regenerated at the next build. Roslyn should allow much of that information to be retained between builds and therefore significantly speed compilation. This will particularly benefit ASP.NET Web sites and the build process within Visual Studio.

4. Is F# part of the Roslyn project?
No, F# isn't part of the Roslyn project and will not expose the same compiler APIs as it will for Visual Basic and C#. Roslyn is focused specifically on Visual Basic and C#.

There are several reasons why F# isn't in scope for the Roslyn project. One reason is that the F# compiler is already written in F#, but more so because Microsoft needed to limit the scope of the Roslyn project to a reasonable size. Remember that the languages team is also busy completing Visual Basic 11 and C# 5. There are also multiple aspects of F# that don't map well to the Roslyn APIs, such as the shared symbol model.

5. What design principals have the Roslyn development team followed?
Data structures provided by the Roslyn compilers are immutable and can't be changed by the calling application. This is absolutely necessary to keep from crashing the compiler; also, the potential complexities introduced by allowing changes in the compile process are prohibitive.

The syntax tree provided to Roslyn consumers is a read-only snapshot of the compiler's current understanding of the code. Re-creating a full syntax tree at each code change would be prohibitive from a performance and memory consumption perspective. The Roslyn team had the challenge of how to quickly surface a complex immutable data collection from a core syntax tree that was modified live as the code changed.

6. What are some of the practical uses for Roslyn? How will it help me as a developer?
One of the first uses of Roslyn that comes to mind is that of a business rules engine. Prior to Roslyn, evaluating user macros typically involved implementing Visual Basic for Applications (VBA), calling out to the DLR with Ruby expressions, or shelling out to the command-line compiler with dynamically generated Visual Basic or C# code and obtaining the result of running that code. These methods were less than ideal.

Roslyn will easily allow dynamic compilation and execution of C# and (eventually) Visual Basic code with the Evaluate() function, as demonstrated Eric Vogel's article "Using The Roslyn Scripting API in C#". User macros written in the same language as the application will make it easier for developers to support user macros representing business rules.

Code refactoring becomes much easier with Roslyn. Prior to Roslyn, the developers of such tools as DevExpress CodeRush and Refactor Pro and JetBrains ReSharper had to recreate much of the compiler operations as a foundation for their products. With Roslyn, refactoring developers can directly take advantage of the existing compiler capabilities. I can imagine the appearance of NuGet packages to install individual refactoring rules once Roslyn is widely available.

7. What are some of the core concepts I'll have to learn to take advantage of Roslyn?
My senior year project in computer science at Michigan State University was to write a compiler from scratch. In order to graduate, my team partner and I had to demonstrate the ability to write, compile and successfully run a program of specified capabilities in our own compiler. Many of the concepts I learned 30 years ago in that project appear in the API exposed by the Roslyn project:

• Syntax Tree. The lexical and syntactic structure of the source code. The process that determines these elements is known as lexicographical analysis
• Syntax Tokens. The end-nodes of the syntax tree, consisting of keywords, identifiers, literals, and punctuation
• Symbols. The distinct elements declared by the source code or imported from an assembly
• Control and Data Flow. Conditional execution of code based on data values
• Error Handling. Ability to report a compilation error in context and in a meaningful way to the developer

8. How will Roslyn influence the future development of the Visual Basic and C# compilers?
Prior to the release of the .NET Framework, I spent several years developing applications with Borland Delphi v3, the Pascal-based compiler also developed by Anders Hejlsberg while he was at Borland prior to joining Microsoft in 1996. The Delphi IDE was written in Delphi and I remember it as a very programmer-friendly and welcoming environment that included many nice touches, likely because the Delphi IDE developers themselves wanted those features. The one that I remember most was a light gray vertical line in the IDE where a code line should be continued if you wanted it to fit out onto the paper when printed.

Roslyn is written with a strong emphasis on parallel tasks. My hope is that any new data structures or techniques developed by the Roslyn team to facilitate multi-threaded operations will find their way into the .NET Framework, such as immutable and read-only collections.

9. Does Roslyn pose any new security risks?
Roslyn can only execute code that any other application could already execute, and runs on the .NET Framework under the same security guarantees. In that sense, it does not introduce any security holes that didn't already exist. But Roslyn does make dynamically executing code much easier than before.

Dynamically executing code at run time has always been a two-edged sword. The potential exists for an application to execute malicious code in a way that may not be easily detected by current virus scanners. Will a Roslyn application that executes the Evaluate() function be permitted in the Windows Store where code safety is a top priority? No word yet.

10. Will Roslyn be released in the next version of Visual Studio?
No, Roslyn won't be ready in time for it to be included in the next version, code-named Visual Studio 11. Microsoft hasn't committed to a release date at this time.

More about the Roslyn project

• S. Somasegar's blog announcing Roslyn

• Channel 9 video, "The Roslyn Project -- Meet the Design Team"

• The Roslyn home page

• Roslyn Project Overview "Exposing the C# and VB compiler's code analysis"

• Walkthrough: Introduction to Scripting

• Walkthrough: Scripting a Paint-like Application