40

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...

gnat
  • 20,543
  • 29
  • 115
  • 306
Richard Hooper
  • 717

4 Answers4

55

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.

RationalGeek
  • 10,077
12

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.

Brian
  • 4,553
10

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++.

BSalita
  • 323
1

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.

John Tasler
  • 21