I have just been reading through some of the white papers & examples from Microsoft "Roslyn" and the concept seems very interesting. From what I can tell, it opens up the black box that is the compiler and provides an interface that we can use to get information and metrics about code written in Visual Studio.

Roslyn also appears to have the ability to "script" code and compile/execute it on the fly (similar to the CodeDom) but I have only come across limited uses for that type of functionality in my experience.

Whilst the code analysis & metrics element is an interesting space...it is something that has been around for a very long time and there are numerous providers that have already invested a lot of money into code analysis & refactoring tools (e.g. ReSharper, CodeRush, nCover, etc) and they do a pretty good job of it!

Why would any company go out of their way to implement something that can be provided at a fraction of a cost through buying a license for one of the existing tools?

Maybe I have missed some key functionality of the Roslyn project that places it outside the domain of the mentioned tools...

  • 4
    The main point of Roslyn is more Microsoft intern - making a easy extensible managed C# compiler. This way the team can easier implement and try out new language features. Also implementing new optimization algorithms will become easier. Jun 11, 2013 at 10:02
  • 1
    Yes Penfold - I suspect you may have missed a few things. Have you watched Dustin Campbells interview on Channel9? channel9.msdn.com/Events/Ch9Live/… Jun 11, 2013 at 10:06
  • 3
    This is the risk of developing successful/profitable add-ons to Microsoft products, they may put it in the next version.
    – JeffO
    Jun 11, 2013 at 12:48
  • 10
    Also, you can be sure the guys behind ReSharper are wetting themselves at the thoughts of the extra functionality they can plug in. Yes, they've written a C# parser/analyzer, but the cost per feature will drop significantly if they can leverage the actual MS C# engine. Jun 11, 2013 at 13:06
  • 2
    Check out scriptcs for an interesting use of Roslyn. github.com/scriptcs/scriptcs Sep 12, 2013 at 2:46

4 Answers 4


Roslyn also appears to have the ability to "script" code and compile/execute it on the fly (similar to the CodeDom) but I have only come across limited uses for that type of functionality in my experience.

On-the-fly compilation and execution is the key benefit of Roslyn. I think you may be undervaluing the benefit of this feature because you have never come across a use case in your experience where it really shines. And this makes sense; the need for dynamic compilation is probably a niche feature, but having it does provide for some powerful applications that would be much more difficult without it.

Here are a couple examples off the top of my head where dynamic compilation would be quite useful. There are other ways to accomplish all of these things, but Roslyn makes them easier.

  • Having plugin files that are loaded at runtime, compiled, and included in the execution of the "parent" application.
  • Creating a DSL which is then translated to C# at runtime and compiled using Roslyn.
  • Creating an programmer-oriented application which takes C#, analyzes it, translates it, etc.
  • Comparing two chunks of code for their differences after compilation, as opposed to just "surface" differences such as whitespace. This is known as Semantic Diff.

So, to sum up, you may never find a use for Roslyn, depending on what software you spend your time writing. However, there are plenty of use cases where Roslyn brings a lot to the table. None of the tools you mention provide this feature. Nor could they based on their architecture and purpose.

  • +1 for sematic diff. For interest here's a link to a commercial product under development which uses Roslyn for semantic diff. (Full disclosure - I have no connection with them, I just saw their product mentioned on Jon Skeet's blog)
    – MarkJ
    Jun 11, 2013 at 12:30
  • @RationalGeek - Thanks for the examples, I hadn't considered the DSL => C# route example...I can imagine a few senarios where that would be very powerful in business applications. A lot of the other examples that I have seen (not just yours) very much overlap with the refactoring tools I mentioned before. The other part of my original question was why would someone invest the money in developing tools to perform this analysis when there are some excellent one pre-rolled at a fraction of the cost...but I suppose there is always room for another (hopefully better) set of tools! :) Jun 12, 2013 at 11:20
  • @Penfold there's always room for new developer tools... :-) Jun 12, 2013 at 12:47
  • 1
    Semantic diff is not just for compilation purposes. Every Version Control System needs a diff, and most use a stupid diff. Just swap 2 functions and see the mess made, when the diff thinks it can match a few ( and {.
    – MSalters
    Nov 15, 2013 at 12:25
  • Here's a big one: automatic re-compilation when writing ASP.NET apps WITHOUT having to rebuild & redeploy the web app. Finally announced in ASP.NET vNext, it will quite literally make working in C# the same as a scripting language... except it is both typesafe AND performant. I see this as the very beginning of this general approach, eventually will make its way into rich-client apps (mobile, desktop) so that you can change your code at runtime. It's much easier with web apps since by definition each request is stateless - but in time it will make its way into other app architectures as well.
    – Marchy
    May 16, 2014 at 15:38

I'm sure companies which provide tooling (e.g., JetBrains*) are very interested in Roslyn. Microsoft wants to make it easy to make tooling, because good tooling encourages the use of Microsoft's ecosystem.

*Per the JetBrains blog (this entry), JetBrians has announced that they will not be using Roslyn. However, I imagine that any new competitors to JetBrains (who don't have a pre-existing codebase to work from) will use Roslyn; it gives them a head start.

Question 6 in 10 Questions, 10 Answers on Roslyn:

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.

  • 4
    "User macros written in the same language as the application will make it easier for developers to support user macros representing business rules." - what could possibly go wrong!
    – gbjbaanb
    Jun 12, 2013 at 11:55

I eagerly await the day when all compilers routinely offer Compiler as a Service (CaaS). We need to stop thinking that compilers emit only pre-linker code and start thinking that compilers emit trees which can be transformed into multiple targets. All compilers should have a feature to emit trees and optionally JSON/XML. The output can then be transformed into many types of targets such as beautified same language, C, IL source, IL binary, Java, Javascript, LLVM, PIC executable, and even pre-linker code.

I write compilers for a living. My customers are sold on CaaS because it opens the door to fantastic flexibility, portability and analysis.

I'm really disappointed that Microsoft hasn't implemented CaaS a long time ago. For example, it could have been used as a migration path for VB6 to something else, or .Net to C++.


The simple answer for why MSFT is investing in Roslyn is that their existing codebase for the C# compiler is now 5 versions old - 11 years now. That's a long time for any codebase to remain manageable. Plus, since they're rewriting, they decided to invest in doing it so that all of its internals are exposed as API's.

Not the answer you're looking for? Browse other questions tagged or ask your own question.