ReSharper and Roslyn: Q&A

Jura Gorohovsky

As you probably know based on news from BUILD Windows conference last week, Roslyn, the new .NET Compiler Platform with code analysis APIs for C# and VB.NET, has been pushed to Preview phase and open sourced. In case the event slipped your attention, here’s a nice tour of Roslyn on the C# FAQ blog at MSDN.

Immediately we at JetBrains were faced with multiple questions on the perspectives of ReSharper using Roslyn for its code analysis and how the two tools might compete. The flow of questions wouldn’t end, to the point of introducing a template to answer them:

ReSharper and Roslyn? I dare you!!

Seriously though, it was clear that we needed to elaborate on the ReSharper vs Roslyn issue. Hence this post.

We sat down with Sergey Shkredov (@serjic), ReSharper Project Lead and .NET Tools Department Lead at JetBrains, and Alex Shvedov (@controlflow), a Senior Developer on the ReSharper team who’s responsible for ReSharper’s Generate functionality, code annotations and support for XML-based languages. The following Q&A is a summary of the conversation that we had with them.

What’s JetBrains stance towards Roslyn? Do we consider the technology and its Open Source status important and valuable?

Roslyn is definitely important and a good step forward for Microsoft in that it should help Visual Studio users take advantage of more C# and VB.NET code editing and analysis features in Visual Studio out of the box.

It should also help Visual Studio extension developers write code-centric extensions against a consistent API while having the opportunity to know how it works inside, thanks to the Open Source status of the project. This is not to mention hackers who are willing to spend their time forking the compiler and tuning it to make, say, C# the ideal language they’ve always envisioned.

We also believe that Roslyn is no less important for Microsoft itself. Faced with the burden of maintaining a plethora of Visual Studio integrated tools including code editing tools, IntelliTrace and code designers, the folks at Microsoft are interested in making these tools as flexible and easy to update as possible. Roslyn should enable updating .NET languages and experimenting with them faster than before. Apart from that, the old compiler wouldn’t let launch compilation steps in parallel, and Roslyn is expected to enable that, bringing more scalability to the table.

What’s the point of making Roslyn Open Source?

As to the act of letting Roslyn go Open Source, we don’t believe that Microsoft is expecting anyone from outside of the company to develop the compiler for them. Programming languages are entities too monolithic and complex to justify accepting external changes of any significance. Therefore, we expect Microsoft to keep the function of designing .NET languages totally to itself without depending on the community.

The true value of Roslyn going Open Source lies in enabling extension developers to look into Roslyn code that is relevant to their purposes: how it’s written and whether it’s efficient. They might debug or profile it to see if it’s the culprit of unexpected behavior in their extensions or if it introduces performance issues. This is possibly the workflow whereby meaningful pull requests might start coming in to the Roslyn repository.

As to possible endeavors to fork and modify the compiler to address application- or domain-specific tasks, this scenario appears to be a shot in the foot. Even if the default compiler in Visual Studio can be replaced with a fork, instrumental support for the fork ends as soon as you go beyond Visual Studio. In theory we can imagine a custom INotifyPropertyChanged implementation based on a Roslyn fork that can even gain certain popularity. However, we can barely imagine supporting it in ReSharper as our intention is to focus on supporting the official version of Roslyn.

Will ReSharper take advantage of Roslyn?

The short answer to this tremendously popular question is, no, ReSharper will not use Roslyn. There are at least two major reasons behind this.

The first reason is the effort it would take, in terms of rewriting, testing and stabilizing. We’ve been developing and evolving ReSharper for 10 years, and we have a very successful platform for implementing our inspections and refactorings. In many ways, Roslyn is very similar to the model we already have for ReSharper: we build abstract syntax trees of the code and create a semantic model for type resolution which we use to implement the many inspections and refactorings. Replacing that much code would take an enormous amount of time, and risk destabilizing currently working code. We’d rather concentrate on the functionality we want to add or optimize, rather than spend the next release cycle reimplementing what we’ve already got working.

The second reason is architectural. Many things that ReSharper does cannot be supported with Roslyn, as they’re too dependent on concepts in our own code model. Examples of these features include Solution-Wide Error Analysis, code inspections requiring fast lookup of inheritors, and code inspections that require having the “big picture” such as finding unused public classes. In cases where Roslyn does provide suitable core APIs, they don’t provide the benefit of having years of optimization behind them: say, finding all derived types of a given type in Roslyn implies enumerating through all classes and checking whether each of them is derived. On the ReSharper side, this functionality belongs to the core and is highly optimized.

The code model underlying ReSharper features is conceptually different from Roslyn’s code model. This is highlighted by drastically different approaches to processing and updating syntax trees. In contrast to ReSharper, Roslyn syntax trees are immutable, meaning that a new tree is built for every change.

Another core difference is that Roslyn covers exactly two languages, C# and VB.NET, whereas ReSharper architecture is multilingual, supporting cross-language references and non-trivial language mixtures such as Razor. Moreover, ReSharper provides an internal feature framework that streamlines consistent feature coverage for each new supported language. This is something that Roslyn doesn’t have by definition.

Will it be practical to use both ReSharper and Roslyn-based functionality in Visual Studio?

This is a tricky problem as it’s still uncertain whether we would be able to disable Roslyn-based features (such as refactorings or error highlighting) when integrating into new releases of Visual Studio. If we’re unable to do that, performance would take a hit. Apart from ReSharper’s own immanent memory and performance impact, Roslyn’s immutable code model would increase memory traffic, which would in turn lead to more frequent garbage collection, negatively impacting performance.

We’re hopeful that this problem would be solved in favor of letting us disable Roslyn features that ReSharper overrides, because otherwise ReSharper would have to work in a highly resource-restricted environment. Irrelevant of whether this happens though, we’ll keep doing what we can do, minimizing ReSharper’s own performance impact.

As Roslyn is now Open Source, which parts of its code are going to be of particular interest to ReSharper developers?

We’ll be sure to peek into Roslyn code and tests from time to time, to see how C# and VB.NET language features are implemented. We don’t rule out that actual code supporting them is going to emerge before formal specifications are finalized. In fact, we’ve already started.

That’s more or less the picture of living in the Roslyn world as we see it today. As time goes by, we’ll see if things turn out the way we expected them to.

Meanwhile, if you have questions that were not addressed in this post, please ask in comments and we’ll try to come up with meaningful answers.

Comments below can no longer be edited.

68 Responses to ReSharper and Roslyn: Q&A

  1. Jean-Marie Pirelli says:

    April 10, 2014

    Thanks for being honest like that.
    I was not expecting you guys to use Roslyn, to be honest. Simply because Roslyn will be integrated in VS 13+ only and R# supports older versions of VS.

    • Jura Gorohovsky says:

      April 10, 2014

      Yes, this is another good reason not to. It’s probably worth another 10 years before VS 13- releases become irrelevant.

  2. Michael Damatov says:

    April 10, 2014

    I’ve not expected from JetBrains to adopt Roslyn, however, I do expect from you to use Roslyn to verify assumptions you have been made during the development of ReSharper.

    • Jura Gorohovsky says:

      April 10, 2014

      Thanks. We’re going to use (as we’ve traditionally used) all sources of information about languages in VS that are available to us, and the list now includes Roslyn. As written above, We’ll be sure to peek into Roslyn code and tests from time to time, to see how C# and VB.NET language features are implemented.

  3. Sebastiaan Dammann says:

    April 10, 2014

    It would be great if R# would not disable code refactorings using Roslyn as they are quite easy to write.

    • Jura Gorohovsky says:

      April 11, 2014

      We’re hoping there would be a choice to use ReSharper with or without Roslyn-based features, just like currently there’s a choice to disable VS native refactorings and IntelliSense or keep them enabled. A different story is the performance impact caused by concurrent usage of the two. We’ll see how significant it would be in practice as soon as VS vNext emerges.

  4. David Zidar says:

    April 10, 2014

    Although I understand your reasoning it makes me disappointed. ReSharper performance has been an issue for years and despite your claims of improved performance it still takes 10+ minutes for ReSharper to do a solution wide analysis of the project I’m working on. Roslyn completes in a fraction of the time.. and in the background.. also something ReSharper could do more of, don’t lock the UI thread.

    It wouldn’t be such an issue if ReSharper didn’t also frequently forget what it knows and restarts analyzing from scratch. Far too often I find it faster to rename classes or properties by hand than let ReSharper do it, again Roslyn does the same task much faster.

    So at least make some features optional, I know I’d much rather rename properties with Roslyn than with ReSharper.

    • controlflow says:

      April 10, 2014

      1. Roslyn has NO solution-wide analysis. This feature is unique for ReSharper. We are tracking dependencies between files and incrementally re-analyzing them to provide features with knowledge of all the solution, all the types defined, all the members used. If you don’t like SWA and it’s performance impact, you can simply turn it off (for example, I’m working with it’s disabled).

      2. ‘Roslyn completes in a fraction of the time’ – I guess, what you talking about is indexes/caches build time. This is required step for any IDE tooling, it doesn’t involve any kind of code analysis. Even in a super-huge solution like R# solution itself (300 projects), cold caches build (solution was never opened before) takes no longer than 40-60 seconds (you may see this as ‘Processing files’ in R# status bar). This is really fast comparing with amount of work and we always working to improve this.

      3. All our inspection are running out of UI thread.

      4. Roslyn is faster in rename refactoring by now because it can’t rename member references from XAML, from ASPX, from Razor. It can’t rename related members (parameter names from base/derived class members) of all kinds (like WPF dependency properties represented as multiple members).

      We also have plans to make our rename faster or at least give you the ability to control the amount of “smartness” you’re expecting from refactoring.

      Thanks for you feedback!

      • David Zidar says:

        April 10, 2014

        1. True. I do like SWA though, the value it provides i great. That’s why I still keep it enabled despite all it’s problems, but it’s getting increasingly worse, like false positives so I have to shut down VS, clear the cache and rebuild from scratch (which takes 10 minutes) and like I said it frequently restarts from scratch by iteself. I love it, but it’s a pain.

        2. I’m talking about the time it takes to get warm enough to perform some kind of refactoring.

        3. Something, or several things, in ReSharper frequently locks the UI though so VS feels laggy and non responsive. All such problems completely disappear when I suspend R#.

        4. Good to know!

        Thanks for responding!

  5. Mike Andrews says:

    April 10, 2014

    I appreciate the post guys!

    I also have been curious since the announcement, but I had already surmised that it would be remiss of JetBrains to attempt an excising and refactoring project of this magnitude for a decade-long development project such as Resharper where none is needed and frankly is supperior in some respects to Roslyn.

    I have used Resharper since version 4.0 and I plan to keep on using it. It’s been my best development tool for many years and I don’t plan on stopping now, regardless if it uses Roslyn or not.

    Just as others have pointed out, I too have performance issues with Resharper that still plague me and disabling it does seem to improve Visual Studio performance in general and I do on occasion when it’s particularly bad. However, I’m willing to take the performance hit as needed because of the productivity gain. Although in light of the admonition of the 300+ project solution, on which I’m sure Resharper is used, I find my pitiful 100+ project solution that bogs down to be highly suspect and that perhaps it’s other issues, such as virus scanners or other services running that are out of my control, that ultimately affect performance, not Resharper.

    In any case, thank you JetBrains for all your hard work and dedication! I’m a very satisfied customer.

    • Jura Gorohovsky says:

      April 11, 2014

      Thanks for your supportive comment, Mike.

      We are indeed using ReSharper when developing ReSharper, which allows us to quickly solve the first wave of issues, performance-wise or stability-wise.

      However given the enormity of environments that ReSharper operates in (which are shaped by Visual Studio versions including updates, operating systems, hardware configurations, .NET framework versions, external libraries, other VS plugins and extensions, as well as countless variations of size and structure of end-user solutions), we can’t ensure optimal performance in all possible combinations upfront.

      That’s why we always ask users who experience severe performance issues to profile Visual Studio and provide us with snapshots. In your particular case we’d also like to take a look at a snapshot of VS with your solution while it’s working slow. Whenever the performance problem occurs and/or intensifies, please consider taking a snapshot by going to ReSharper > Help > Profile Visual Studio and sending it our way for investigation.

      If we find that ReSharper is guilty, we’ll make optimizations in the next release. If we find that it’s something else that contributes to the lag the most, we’ll at least let you know what’s going on.

      Meanwhile, you might want to spend ~half an hour fine-tuning your environment in ways that could make VS and ReSharper work faster. For the list of things to check, you can refer to this guide.


  6. Roslyn! It’s got Electrolytes! | In Absentia says:

    April 10, 2014

    […] 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 […]

  7. Fujiy says:

    April 11, 2014

    Most of people was hoping that Resharper could finally been faster with Roslyn. I use ReSharper for many years, and the performance impact is huge. I tried on different machines, sent profile files to ReSharper team, etc.
    Its a consensus that ReSharper slows down VS

    • controlflow says:

      April 11, 2014

      So… you think we should drop support all the languages except C# and VB.NET, take a few years to rewrite our features to do AST transformations in a immutable way, write missing parts (currently Roslyn is less than 5% of R# by the number of LOC), drop our caches to do fast find usages (just compare it with Roslyn’s on a huge solution) and fast inheritors lookup (without iterating all of the files in solution), completely drop solution-wide analysis… and this will make as faster and a greater product?

      Or you think it is possible to abstract features over immutable AST in a just two languages and a mutable one in any other? What for? Just to share syntax trees? Parsing is really really cheap comparing to semantic resolution (ask Roslyn folks).

      • David Zidar says:

        April 11, 2014

        Maybe it’s time for a new product, a ReSharper Lite or something?

        Also, don’t underestimate perceived performance. You may have the worlds fastest parser or code analyzer but it will still feel slow if something else keeps locking the UI. R# really is the biggest performance thief I still have installed.

      • Fujiy says:

        April 13, 2014

        Maybe Roslyn can’t help to solve performance issues, or is not feasible.

        But that was what many people was hoping

        ReSharper is great, but I can’t convince some people to use, because until you learn how to use it, the only thing that it does is it slows down the IDE

        • Jura Gorohovsky says:

          April 14, 2014

          ReSharper is great, but I can’t convince some people to use, because until you learn how to use it, the only thing that it does is it slows down the IDE

          Brilliant. I think I will print this on posters and hang them on a few walls )

          • Petr K. says:

            April 16, 2014

            Not sure if the sarcasm is really appropriate. Unfortunately, this thinking really IS common amongst developers.

            • Jura Gorohovsky says:

              April 17, 2014

              Wasn’t meant as sarcasm at all, Petr. I simply find this sentence a perfect call to action.

  8. 13xforever says:

    April 11, 2014

    I hope that R# will support the ability to use custom C# features, though I cannot think how you might be achieving this without using the modified Roslyn which supports these features.

    • Jura Gorohovsky says:

      April 11, 2014

      When you say “custom C# features”, do you mean language features implemented in unofficial forks of the compiler? If this is what you mean, then unfortunately we’re not planning to do that. However we’re surely going to support all new language features implemented in Microsoft-maintained repository.

      • Vladimir Reshetnikov says:

        April 16, 2014

        To make things clear, there is no “Microsoft-maintained repository”. The Roslyn repository at CodePlex was published by MS OpenTech, a legal entity distinct from Microsoft Corp.

        MS OpenTech is the copyright owner and licensor, and has admin permissions for the repository. The repository is maintained by the community.

        • Jura Gorohovsky says:

          April 17, 2014

          Thanks for noting, Vladimir, although it doesn’t make it any clearer as to who decides to maintain it in one way or another.

          • Vladimir Reshetnikov says:

            April 18, 2014

            Microsoft still owns C# and VB language specifications, and has ultimate control over the language design process (although the community input, particularly, through discussions on CodePlex, has a significant impact on it too).

            But the actual implementation is up to the contributors of a particular project (such as Mono or Roslyn), and Microsoft has no responsibility for fidelity, correctness or intellectual property used in those projects. Still, we (test team) at Microsoft take much effort to test the open-source Roslyn project against the language specifications (and drafts) and file issues for all bugs and deviations found.

            • controlflow says:

              April 18, 2014

              So, VisualStudio 2014 will ship (Mads announced that) with other, internal Roslyn build that Microsoft ‘has responsibility for fidelity, correctness or intellectual property used’?

              • Vladimir Reshetnikov says:

                April 18, 2014

                The current plan is to use some stable branch of the open-source project

  9. نگاهی به Roslyn | A Geek NotesA Geek Notes says:

    April 11, 2014

    […] در این بین واکنش jetbrains هم برای استفاده از Roslyn در ریشارپر جالب بود.که آنها […]

  10. Joe White says:

    April 13, 2014

    Good post; thanks for laying out the reasons so clearly.

    I wonder whether there’s a way you could take advantage of Roslyn’s test suite to find things like compiler errors that R# doesn’t yet recognize.

    • Jura Gorohovsky says:

      April 13, 2014

      Joe, there should be a way to take advantage of the test suite in terms of any errors and warnings that we don’t recognize, as well as to explore their performance testing practices.

  11. Hannes K says:

    April 13, 2014

    As I knew the answer to the question “will R# use roslyn” because I asked it in another thread already.. I’ll reiterate in different words: you are going down a lonely road. It’s doubtfull you will be able to shutdown Roslyn, even more doubtfull your customers will want you to, seeing some of the core VS experiences like edit-and-continue will rely on it.

    This puts you in a bad spot, because thanks to Roslyn simple R#-like features will crop up through community extensions, and then it will start to be a decision between “use extension X Y Z with minimal perf impact” and “use the whole featureset of R# with big perf and loadtime hit”, and over time that decision will get more and more biased towards the community extensions, as their featureset will grow. Of course that’s part of the reason for your work on the SDK, and on perf improvements lately, I understand that, you saw Roslyn coming for a long time. That also means the decision was made a long time ago. Still… unfortunate.
    We need a more nimble, modular, faster R#. If you invest the time to improve loadtimes, make R# load async, etc.. you could as well switch to Roslyn. Just bite the bullet.. please. 😉

    • controlflow says:

      April 14, 2014


      1. “It’s doubtfull you will be able to shutdown Roslyn…” – maybe this is not clear from the post, but are not going to ‘shutdown Roslyn’. Yep, core VS features will rely on Roslyn – compilation, edit & continue, debugging, any other VS feature that uses C#/VB language services. What we want is the ability to replace features we can do better/faster/cross-language/etc, just like we doing with the VS features by now, overriding some menus, replacing code completion, etc.

      2. We always, always investing in R# performance. We improving our caching every release (we moving our caches to leveldb), we offloading cold data from memory, we reducing memory traffic and GC pressure, trying to use new faster algorithms and data structures, inspecting JIT time (we use CLR4.5 multicore JIT to reduce startup time), dropping closures/de-functionalizing our code in a hot paths and a LOT more! We are trying to be async as we can, but a lot of communication with VS APIs should be done exclusively on the UI thread and some of APIs may be really slow (project model).

      3. Yes, modularity is very important. I think we can greatly improve this part in the future 🙂

  12. Jeremy Foster says:

    April 14, 2014

    Good thread. I would agree that it would be helpful to have a R# Lite. I was having bad performance problems in VS13 recently and ruled out R# as a culprit because I suspended it and the issue remained. A colleague informed me that suspending R# was not enough. It had to be uninstalled. I uninstalled and VS was speedy again.
    I love most of the features of R#, but there are only a handful that are live or die for me and they’re little things like Expand or Shrink Selection, Introduce Variable, etc. If community contributions on Roslyn start filling those holes, I’ll have a harder time justifying the R# performance impact especially given the fact that I don’t much use some of the more perf expensive features.
    Thanks for the great product and the great blog post.

    • Jura Gorohovsky says:

      April 17, 2014

      Jeremy, thanks for your comment. We’ll be actively looking for other holes though and we’ll be finding them.

  13. Ilya says:

    April 15, 2014

    I have been using R# for more than a decade now, and I have to admit I’m disappointed. I do realize that Roslyn is 5% of R#, I do realize that it is nearly impossible to make the kind of business decision.

    But I also feel like I’m using only 5% of R# too. I feel (and it is just a feeling right now) that in a few years community is going to write 5% of features of R# that I use 95% of the time and it is not going to be that hard of a choice. I’m afraid it’s not going to be in favor of R#.

    • Jura Gorohovsky says:

      April 17, 2014

      Thanks Ilya, we’ll see how it goes.

  14. MindLogics says:

    April 16, 2014

    Good post; thanks for laying out the reasons so clearly.

    • Jura Gorohovsky says:

      April 17, 2014


  15. Petr K. says:

    April 16, 2014

    So, what’s your stance on the fact that CodeRush will integrate Roslyn to achieve performance gains and memory optimizations?


    To be clear, I’ve never used CodeRush, but from what I hear, its feature set and performance is on par with ReSharper, if not superior in certain cases. Except apparently they are willing to bite the bullet and give their users the opportunity to benefit from Roslyn.

    • Jura Gorohovsky says:

      April 17, 2014

      All the luck in the world to them, first of all.
      Then, they do provide a limited set of features that is superior to ReSharper (their templating engine for example is more flexible) but in terms of analyzing code, I’m afraid they’re behind. That said, they might benefit from Roslyn code analysis per se.

      • Patrick Smacchia says:

        April 17, 2014

        I just wrote about this, Roslyn vs. R# vs. CodeRush, + my position with NDepend:

        This is pretty risky to force users to host two compiler/analyzer in its own process. But in parallel hardware is getting faster.

        Also once the investment done, CodeRush will have language future evolution almost for free, which can pay off in the long term.

        Anyway, that’s great insight to know more about your strategy, and I wish you all the best with your choice.

        • controlflow says:

          April 17, 2014

          Pretty risky, huh? How everything is working now in VS? Current unmanaged C# language service is more memory hungry than Roslyn: 150-200Mb difference on R# solution 😉

          Future evolution for free? It’s a myth 🙂 Yep, Roslyn will bring new C#/VB features parsing support and semantic resolution first, but this is just a small part of a language feature ‘support’. Roslyn doesn’t solve the need of reviewing and updating tons of context actions/quick fixes, all our refactorings and other features unique for R#.

          Let’s see how it goes in the long term 🙂

          • Patrick Smacchia says:

            April 18, 2014

            Sure it’ll be interesting to see where the tooling will be in five years, in ten years, from now.

  16. No, ReSharper will not use Roslyn | Dip Thoughts says:

    April 17, 2014

    […] The actual blog post can be found here. […]

  17. C-J Berg says:

    April 25, 2014

    I don’t doubt that ReSharper’s code analysis is truly top notch under the hood, but isn’t there a lot of performance related issues simply related to integrating with Visual Studio? After all, there’s a lot of old fashion stuff involved, like COM interop and whatnot, and you can’t have perfect control over the IDE environment. Even a clean install of Visual Studio is far from snappy compared to other modern IDEs. And that awfully slow VS install/update process… But I digress.

    I’m thinking JetBrains would be exceptionally well-positioned for creating an alternative IDE to Visual Studio, based on the successful IDEA-technology. If I could buy a .NET IDE that provided me with ReSharper’s analysis and refactorings, some WebStorm-like web development support, and all the other great stuff that IDEA-based IDEs bring along… well, I’d buy it in an instant. It could blow Visual Studio out of the water. Please consider it some day. 🙂

    • Niels Jørgensen says:

      April 25, 2014

      Dead on!

      I have all my fingers crossed that this is what will finally get you guys to do a complete C# IDE – we all know it’s going to be awesome 😉

      I too would pick “IDEA for C#” over VStudio (roslyn or not) any day of the week (keeping it on the IDEA platform, written in Java, would be both cool and quite ironic. And it would allow me to develop C# natively on my Mac, Yay!).

      I am currently using both AppCode and IDEA on a daily basis and love them, but also do a fair amount of Unity development and am forced to either run Windows/VStudio parallel to OsX, or use MonoDevelop which is a royal pain in the neck.

      Anything – and I mean *anything* – you could cook up in the area of a cross-platform C# IDE would be infinitely better than Mono and I would buy it instantly.

      • Eyal Shilony says:

        August 9, 2014

        Exactly! I’d be one of the first to buy it, just leave VS or well, continue to support it but let some of us enjoy IDEA for .NET development! 😀

  18. CodeRush vs ReSharper (the Roslyn debate) | Paul Usher says:

    April 25, 2014

    […] NO […]

  19. Michael says:

    April 26, 2014

    LOL an IDE by JetBraind for C# is never going to blow VS out of the water, you are crazy people.

    • Marcel Bradea says:

      May 16, 2014

      You would be very surprised. AppCode on the Mac did that to Apple’s Xcode, and IntelliJ is a much faster/better IDE to develop Java code in than Visual Studio is C# – the reason why Google has chosen it as its official IDE for Android, rebranded as Android Studio.

      I think if JetBrains was given a clean slate they would be able to build a much better / faster / less monolithic IDE than Visual Studio has become over its many generations. Just look at the experience JetBrains has building IDE’s across many languages/OSes/stacks. The Visual Studio team doesn’t have nearly the expertise/experience. Sorry to say.

      What is your stance on finally building a cross-platform .NET IDE? With Rosyln open-sourced, and ASP.NET vNext officially opening the doors to Mono ( we could finally write code in an operating system we LOVE (OS X) while using the world’s most modern and advanced language – C#.

      Today we have to choose: crappy OS/apps/environment (Windows) VS crappy coding languages (Java, PHP, etc.). I see the open-sourcing of .NET as being the key opportunity for you guys to set out on building a fantastic IDE on BOTH Windows and the Mac to leave the likes of MonoDevelop and Visual Studio in the dust. Without pre-announcing anything you might have going in stealth… what is your stance on this being a trigger for you to set out on this much-needed initiative?

      • Jura Gorohovsky says:

        May 16, 2014

        Thanks Marcel.

        There’s no change in this regard though. We’re not currently planning to build a .NET IDE, cross-platform or otherwise.

      • Eyal Shilony says:

        August 9, 2014

        Even though I want them to create IDEA for .NET developers as an option, you’re quite wrong the VS team has quite a lot of experience the issue is not the team but with VS that over the years the internal components never changed much, adding a feature required a lot of infrastructure work and speaking to old components is not fun, not to mention the huge dissonance between VS and the languages themselves and the long development cycle of VS where bug fixes took ages to finally get fixed.

  20. Neal Gafter says:

    May 12, 2014

    You wrote “… Roslyn’s immutable code model would increase memory traffic, which would in turn lead to more frequent garbage collection, negatively impacting performance.”

    That theory illustrates a deep misunderstanding of functional data structures. Fortunately it is not borne out in practice.

    • controlflow says:

      May 12, 2014

      Well, there is a bit misunderstanding here.

      We know what functional data structure is and using some of them in R# codebase. We perfectly know the benefits functional data structures provide: with immutable trees you can share parsing results between incremental parsings (and reduce allocations count), easily have snapshot functionality like you have in Roslyn, easily share trees between concurrent tasks and so on.

      But, of course immutable trees have one issue – there is no .Parent node references there. You can write a lot algorighms and features without parent node reference, but having parent references is VERY handy in IDE tools development. This is why you have two immutable trees – “Green” and “Red” one. Green tree is built by parser and have no parent references. Red tree is built on-demand over existing Green tree and provide user with .Parent references.

      Since most of Roslyn diagnostic functionality traverses exactly Red tree, we expecting extra memory traffic happens because of Red tree on-demand allocation. We will be happy if this will not became the issue in practice, when a lot of diagnostic analyzers will be implemented.

      Talking about practice, while Roslyn still is not able to compile ReSharper solution because of bugs, it takes about ~10-12 minutes to build indexes at cold VS start (~1 minute for R#). Heap usage looks very unpredictable while index is building – it jumps from 0.9Gb to >2.0Gb between GCs every 10-20 seconds. Also index build process seems to be single-threaded (why so?).

    • Kirill Skrygan says:

      March 25, 2015

      Regarding the practice.
      Solution with 320 projects. VS CTP6.
      Just typed for 20 seconds in a 200-lines of code file. Etw shows there were allocated about 820 MB.
      Although UI thread is pretty free, as a user I constantly feel this lagging.

  21. .NET Developer Tooling: The Roslyn Revolution | Dot Net RSS says:

    May 15, 2014

    […] VS process. This will have a crucial consequence on both memory-consumption and performance. Not using Roslyn is the choice of the R# team and I am worried a bit since I am a big fan of […]

  22. jrg says:

    May 20, 2014

    Please improve/extend tools like “search with pattern”, and the R# SDK in order to offer a powerful alternative to Roslyn to the ones that wish to develop third-party analysis tools and code-quality-tools (dependency checker, code-design rule checkers). R# is the leader in matter of .Net code analysis, but lack of low-level customizations.

  23. Stacey says:

    June 10, 2014

    I am pretty sure that this could all change 10 or 15 times before Visual Studio 2014 actually lands in RTM, though. We should all know by now that the programming world changes every few minutes – anything can happen.

  24. Retour sur NCrafts / Le projet Roslyn | Cellenza Blog says:

    July 29, 2014

    […] qu’elle n’utilisera pas Roslyn lorsque cet outil sera disponible dans sa version définitive (point de vue de l’équipe resharper sur le sujet). Tout ceci promet de futurs trolls très animés […]

  25. Is Microsoft Going Open Source? - Blog says:

    August 1, 2014

    […] that previously required purchasing third party tools such as JetBrains’ Resharper. That said, Resharper will still have its place even with […]

  26. Roslyn (.NET compilers as services) now open source | Visual Studio Extensibility (VSX) says:

    August 8, 2014

    […] What to do if you have a huge investment in the previous technologies (automation code model or your own parsers). For example, ReSharper has decided not to use Roslyn… […]

  27. Roslyn, the C# (and VB) .Net compiler platform | Wimpies C# Blog says:

    August 12, 2014

    […] toolmakers have already their extensive own (optimized) code base. See for example the bog post ReSharper and Roslyn: Q&A. Newcomers however can profit from the work already available from […]

  28. Alex says:

    December 15, 2014

    With Roslyn it will be possible to debug lambda expressions. If Resharper is not going to support Roslyn, will we loose on this new feature?

    • Alexander Shvedov says:

      December 15, 2014

      No, you won’t lose this feature. ReSharper is a design-time tool for source code (mostly), we do not integrate into any of VS debugging capabilities. So as usual, compiling your code, debugging, intellitrace and edit & continue goes through old C# or new Roslyn compilers, R# has nothing to do with it.

  29. Michael says:

    June 15, 2015

    I’ve been a long time advocate for tools like Resharper; it’s saved me and the teams I’ve worked with countless hours performing code analysis, refactoring, and other daily challenges. Even menial stuff like discovering assemblies and making the appropriate references, is indispensable, IMO.

    However, the short answer of “no” is disappointing to say the least. The times are changing, whether we like it or not, the OSS march is in full swing. Has been for well over a year now, in relevant C# .NET stacks. That’s not changing any time soon that I can surmise. The fact of life is that it is tough to keep pace when the sands are shifting so quickly, but that’s just the fact of life we must all deal with.

    Hopefully you change your minds on this and make the necessary changes to keep pace.

  30. Jeff says:

    July 24, 2015

    I have been using CodeRush and ReSharper together, in my day to day work, for many years.

    I stopped to pay my CodeRush licence last year, the reason is its performance is not getting better, and there isn’t much new feature coming along.

    However, I recently find ReSharper’s performance for large solution is getting worse, especially the poor performance on Code Analysis. I have to disable solution-wide code analysis, and even file-level analysis sometime. The intellisence’s performance is not that good neither.

    A performance benefit from using Roslyn ( from CodeRush ), even they do not mention competitor’s name, but I believe everyone knows.

    Their ‘CodeRush for Roslyn’ is under preview stage, and planing to complete all features by the end of this year. Therefore, R# has another 5 months to think about it (I mean if you want).

    I think Roslyn is more than just compiler, it opens an opportunity.

  31. Steve Dunn says:

    September 19, 2019

    5 years on, I’d be very interested to hear what JetBrain’s stance on this now is.

    Do you think not switching to Roslyn was the correct choice?

    There seems to be a lot of Roslyn PRs (, so it _appears_ popular, although I haven’t checked to see how many are external PRs.

    Was Rider a response (at the time) to difficulties in getting such a complex plug-in working efficiently in Visual Studio?

    Genuine questions – I personally *love* R# and I’m a huge fan of JetBrains (since before the reseller days!)

    • Jura Gorohovsky says:

      October 4, 2019

      Hi Steve,

      I’m the author of this post but since I’m no longer at JetBrains, I can’t really reflect whether this choice is currently considered correct or regrettable. I’ll ping someone at JetBrains to provide a comment on that.

      I can comment on Rider however: at the time of publishing this post, Rider wasn’t on the radar at all. It took one more year for the first developer to start experimenting with the IntelliJ platform and come up with the first Rider prototype. Was the experiment a response to the complexity of ReSharper’s integration with Visual Studio? I believe it was to some extent, but to a greater extent it was just that: an engineering experiment, an effort from a part of the dev team to enter unchartered territory. Whenever you try to make sense of what JetBrains does and you need to figure out whether a certain activity was driven by business concerns or an engineering challenge, you can safely bet it’s the latter.


Subscribe to .NET Tools updates