Disclaimer: these are some random musings (read: rant) on the subjects of Roslyn, ReSharper and the future of development tools. While I’m heavily biased towards one of the R’s, I’ll try to keep an open mind. Or not.
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 had ever attempted to build a Visual Studio extension knows very well the limitation of certain APIs. In particular, the Visual Studio automation model (called DTE), and the code model – both very old, at times unpredictable APIs. The only sources of information, other than MSDN and associated forums, are handful of people who have 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 by the fact that each Visual Studio version is different, has different features and own 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 few dozen people, and it’s been this way for a long time. Until now.
When Roslyn was publically announced back 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” – a vast process that 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, Dustin Campbell did it live on stage at Build in about 15 minutes, which was previously unheard of!
The possibilities that are now open to .NET developers are endless, but so are the realities, which is the point (if any) to this post. 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, there’s a second part of the Roslyn story, and it’s the Visual Studio integration and features, currently in Preview stages. Those are not currently open source, and it’s unknown whether they will be at some later stage. Those include base types and internal implementations of refactorings and quick-fixes that ship with the Preview, as well as numerous services that are 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 making sure 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 is there, have been there for a decade, constantly improved. You don’t just replace it. As developers, we have a tendency 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, I’d say the guys over at JetBrains are plenty adulated. The internet is abuzz with talks of Roslyn and ReSharper, and this also must be good for SEO. However, ReSharper isn’t going anywhere, they will continue to do what they do best. And Roslyn? Roslyn will allow for developers who were previously afraid of “black boxes” to develop great tools for their fellow developers. Out of thin air, I predict that within 2 years there will be an explosion of productivity tooling in Visual Studio galaxy, and we’re witnessing its birth. But time will tell.