Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Trying to Live Without ReSharper in Visual Studio 2017

DZone's Guide to

Trying to Live Without ReSharper in Visual Studio 2017

I have been using ReSharper for my day-to-day coding for over a decade, and the workflow it enables is deeply rooted in how I work. Let's see how I manage without it.

Free Resource

Container Monitoring and Management eBook: Read about the new realities of containerization.

This is an experiment that is doomed to fail, but given that I just setup a new VS 2017, I decided to see how it would feel to run it without ReSharper and see how doing so impacts my workflow. Please note that this is very much not an unbiased review. I have been using ReSharper for my day-to-day coding for over a decade, and the workflow it enables is deeply rooted in how I work. I’m going to ignore any differences in key bindings, as irritating as that can be, in favor of just looking at different features.

So far, I spent a couple of days trying to work on VS 2017 without ReSharper. It has been quite frustrating, but I was able to sort of limp along. I most certainly felt the lack.

My hope was that I would be able to see the promised performance improvements without it, and then consider whatever it is worth it. That wasn’t the case.

image

As you can see, ReSharper is not installed, but I managed to get VS into a hang several times. It seems to happen with NuGet or when trying to use the Test Explorer and a few times when I was trying to edit code while the solution was compiling.

Without any meaningful order, here are the things that I really felt the lack of.

  • Go-to definition with automatic decompile is something that I apparently use a lot more than I expected. It helps om figuring out what I can expect from the method that I’m looking at, even when it is not our code that I’m looking at.
  • Refactor method ignoring whitespace lets me just write a statement and it becomes a method name. This is actually quite nice.
  • Quick docs in R# is very nice — the ability to hit Ctrl + Q and get the docs for a method is something that I seem to be using a lot. This is important because I can quickly check the docs (most often, what conditions it has for returning or specific arguments). The key here is that I don’t need to leave my current context. I can hit Ctrl + Q, peek at the docs, and then move on.

image

  • Extract variable isn’t there, so a lot of the refactoring that I’m used to aren’t there or are hardly accessible.
  • IntelliSense is a lot less intelligent. Being able to write a method and just Ctrl + Space all the parameters because R# can fill the context is very useful.
  • Ctrl + N (symbol search) is a lot more useful. I’m familiar with the Ctrl + ; to search solution explorer, but the features don’t compare. In one case, I get live feedback, which means that I don’t have to remember nearly as much about the symbol that I’m looking for. On the other hand, I have to write it and hit enter to see the results. There is also an issue with the presentation. Solution explorer is really poor model for it.
    image image
  • There is a lot of wasted space in the VS model versus the R# model.

Update: I have since learned about VS' Ctrl + , feature, and that seems much nicer — and it also does auto peeking, which I like.

In general, to be honest, R# feels smarter (remember, I’m biased and likely work to the strengths of R#). But another aspect here is that with R#, I rarely have to leave my current context; pretty much everything is available immediately from where I am.

This is true even something as simple as the search above. With R#, this shows up in the middle of the screen. With VS, that is all the way to the right, so I need to move my eyes to track it.

The same is pretty much true for everything else. Reference search in R# shows where I’m looking at right now, and with VS, it shows in a window in the bottom.

Refactoring options in VS show up in the top right, and it is easy to miss them completely. R# put them in the front, along with what you are working on right now.

I’m going to install R# for VS 2017 shortly, and then I’ll be able to compare the speed, but I’m pretty sure that I’m not going to be very happy with that. Then again, once it is loaded, I haven’t noticed R# + 2015 being much worse than 2017 without Resharper.

(Not that I’m doing this during my usual work on a solution with 55 projects and 820 KLOC.)

Update

I have tried R# and VS 2017 for a couple of days now, and I can tell that aside from the project open times (which are absolutely atrocious with R#), I’m not seeing anything major performance wise.

That said, project open time is also “switch between branches,” and that is a major PITA.

Of course, I’m guessing R# is really popular, because:

image

I can guess someone was tired of “Visual Studio is slow” when it is someone else’s code, and they wrote this to point the blame on the relevant extension so the bug report would go to the appropriate people.

Take the Chaos Out of Container Monitoring. View the webcast on-demand!

Topics:
performance ,resharper ,visual studio 2017

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}