Not 10 minutes passed since the Roslyn open-sourcing announcement at Build 2014, which by itself is a monumental, historic event for Microsoft and the .NET community worldwide; some people already started predicting the demise of ReSharper. It’s been a week or so, and JetBrains finally posted a Q&A where they explain their reasons for not moving to Roslyn as predicted, at least not in the foreseeable future. Which, in turn, caused yet another sea of comments, both supporting and condemning the decision.
Now, why do I care?
I’ve been a developer for Visual Studio tooling for a while now. Anyone who has ever attempted to build a Visual Studio extension knows very well the limitations of certain APIs. In particular, the Visual Studio automation model (called DTE) and the code model are both very old and sometimes unpredictable APIs. Other than MSDN and associated forums, the only sources of information are a handful of people with years of painful experience developing on top of those APIs. Asking a Visual Studio Extensibility question on StackOverflow will almost always yield an answer from the same handful of people. You get to know their names, avatars, and positions at various divisions at Microsoft, where they work or worked at some point.
Needless to say, developing Visual Studio extensions is hard. It’s made harder because each Visual Studio version is different, has different features, and has little quirks. To maintain the same, consistent experience throughout all Visual Studio versions requires painstakingly maintain different versions of the same code base, using #if directives, partial classes, linked source files, duplicated files – the list goes on. It’s a dark art, known only to a few dozen people, and it’s been this way for a long time, until now.
Enter Roslyn.
When Roslyn was publicly announced in 2011, it promised to change that. Initially described as a compiler-as-a-service, Roslyn became a promise of a better way developers could interact with what is traditionally a black box. This vast process happens behind the scenes in Visual Studio. Developers now have a chance to use a modern, clean API to do things previously considered impossible on the .NET platform - from turning C# into a scripting language and compiling C# in Swedish to creating quick-fixes and refactorings easily. It’s so easy, in fact, that Dustin Campbell did it live on stage at Build in about 15 minutes, which was previously unheard of!
The possibilities now open to .NET developers are endless, but so are the realities, which is this post’s point (if any). First, let’s peek into the Roslyn box. Roslyn, officially known as the .NET Compiler Platform, is comprised of several parts, mainly the compiler model (syntax tree and semantic model, code parsers, and generators) and a set of diagnostic APIs for building analysis tools, refactorings, and quick-fixes. These APIs are open-source and are available for everyone.
However, a second part of the Roslyn story is the Visual Studio integration and features, currently in the Preview stages. Those are not currently open source, and it’s unknown whether they will be at some later stage (Update: the Visual Studio integration APIs were open-sourced as well). Those include base types and internal implementations of refactorings and quick-fixes that ship with the Preview, as well as numerous services tied directly to core services such as debugger, code editor, and other Visual Studio internals. You can read a great overview of what’s in the Roslyn box in this post by Schabse Laks (another name in the dark art crowd).
So, what does this have to do with ReSharper? Well, simply put, for almost a decade ReSharper provided Visual Studio users with features that were only available on other platforms other IDEs. Over the years, as new Visual Studio versions got some of ReSharper’s features built into it, ReSharper relentlessly continued to innovate with better static analyses and code fixes, while ensuring all those innovations were all supported in older versions of Visual Studio. The latest version of ReSharper (v8.2 at the time of writing) supports almost all the same features on Visual Studio 2005 throughout 2013.
As someone who understands the intricacies of supporting different versions and architectures of Visual Studio I am dumbfounded by the amount engineering effort that went into this. Years of abstracting, refining and stabilizing the layers that make Visual Studio disappear completely, from ReSharper’s point of view, allowing creating plugins for ReSharper that will just work on all supported Visual Studio versions. And if you need to find out how something works? Decompile it! They want you to do it, and even give you a tool for this.
So, should ReSharper switch to Roslyn? JetBrains don’t think so. I don’t think so; why would they? ReSharper’s already got a George - the entire ecosystem has been there for a decade and constantly improved. You don’t just replace it. As developers, we tend to jump on the new shiny, but honestly, how often do you switch out your database? Architecturally, Roslyn and ReSharper differ enough to make this change infeasible, not to mention dangerous - it would require almost a complete rewrite of ReSharper, and as Joel once said, this is something you should never do.
In conclusion, if imitation is the best form of flattery, the guys over at JetBrains are plenty adulated. The internet is abuzz with talks of Roslyn and ReSharper, which must also be good for SEO. However, ReSharper isn’t going anywhere. They will continue to do what they do best. And Roslyn? Roslyn will allow developers previously afraid of black boxes to develop great tools for their fellow developers. Out of thin air, I predict that within two years, there will be an explosion of productivity tooling in Visual Studio galaxy, and we’re witnessing its birth. But time will tell.