.net - Microsoft Roslyn vs. CodeDom

Question

From a press release yesterday on InfoWorld regarding the new Microsoft Roslyn:

The most obvious advantage of this kind of "deconstructed" compiler is that it allows the entire compile-execute process to be invoked from within .Net applications. Hejlsberg demonstrated a C# program that passed a few code snippets to the C# compiler as strings; the compiler returned the resulting IL assembly code as an object, which was then passed to the Common Language Runtime (CLR) for execution. Voilà! With Roslyn, C# gains a dynamic language's ability to generate and invoke code at runtime.

I've been able to do this since the release of .NET 4 with CSharpCodeProvider.CompileAssemblyFromSource which I in fact use in an ASP.Net project written awhile ago that does exactly that - allows a user to type in code into a textbox, choose assemblies/namespaces to reference, and then execute and display the output from that code on-the-fly for live environment code testing on Windows Azure.

Is CodeDom part of / a precurser to Roslyn? What's the special benefit of Roslyn over CodeDom?

Answer 1

Disclaimer: I work for Microsoft on the Roslyn team.

CodeDom is a precursor to Roslyn, but is only marginally related. Essentially, CodeDom is a simple and (somewhat) langage agnostic way to generate code that was added in .NET 1.0 to support designers (a la WinForms). Because CodeDom was an attempt at providing a unified model that can generate code in C#, VB, and other languages, it lacks high fidelity with any of the languages that it supports (that's why you can't create a switch statement with CodeDom). CSharpCodeProvider.CompileAssemblyFromSource is simply a wrapper around executing csc.exe.

Roslyn is a completely different animal. It is a rewrite of both the C# and VB compilers from the ground up using managed code -- C# in C# and VB in VB (the versions of csc.exe and vbc.exe that ship today are written in native code). The advantage of building them in managed code is that users can reference the real compilers as libraries from .NET applications (no wrappers needed).

While building each component of the compiler pipeline, we've exposed public APIs on top:

• Parser -> Syntax Tree API
• Symbol Table/Metadata Import -> Symbol API
• Binder -> Binding and Flow Analysis APIs
• IL Emitter -> Emit API

Roslyn can be used as a sophisticated C# and VB source code generator, but that's where the similarity to CodeDom ends. The Roslyn Compiler APIs can be used to parse code, perform semantic analysis, compile and evaluate code dynamically, etc.

In addition to the compilers, the Roslyn team is also rebuilding the Visual Studio C# and VB IDE features on top of the public compiler APIs. So, the compiler APIs are rich enough to build the Visual Studio design-time tools, like IntelliSense and the Extract Method refactoring. Also, at layers above the compiler, Roslyn offers services for higher-level analysis or data transformation. For example, there are services for formatting code using the C# and VB formatting rules, or finding all references to a particular symbol within a solution.

Really, there isn't just one special benefit of Roslyn over CodeDom. Where CodeDom filled a very specific code generation need, Roslyn is tackling the entire language tooling space by providing a framework to allow you to build just about any sort of C# or VB language tool you can think of.