Introduction

For a number of years I’ve used JetBrains Rider as my primary IDE. Before that, I used Visual Studio with ReSharper installed. I’ve never really used Visual Studio in a professional capacity without ReSharper.

I recently started working on a project which requires Visual Studio for development, so I decided this was a good chance to see what Visual Studio is like to use for day-to-day professional development. This is of course highly subjective, but I wanted to record my impressions.

Keyboard shortcuts

My first immediate problem was that all of my keyboard shortcuts, which I have heavily customised in Rider, don’t work in Visual Studio. This was an interesting opportunity to see what keyboard shortcuts I use most often in day-to-day work. I quickly added a shortcut for opening the Visual Studio settings so that I could more easily customise other keyboard shortcuts.

It was interesting to see what shortcuts I found most important. These were the first to get their shortcuts configured:

• Open git changes (i.e. the code which needs committing)

• Open solution explorer

• Open current file in solution explorer

• Pin current file

• Close all but pinned

• Close other documents (i.e. everything except the current file)

• Close all documents

• Open breakpoints window

• Open GitHub Copilot chat

• Open git history for current branch

For no particular reason, there were two shortcuts I didn’t bother remapping. I just used the Visual Studio defaults for these.

• Shift + Ctrl + T to search for a file by name

• Ctrl + . to open the Quick Actions icon.

The work I was doing didn’t involve many changes for which unit testing would be applicable, so I didn’t configure any unit testing shortcuts. Normally I use them heavily.

Feature differences

There were a number of features which I use in Rider but don’t exist in Visual Studio. I expected this, but I couldn’t have told you in advance what features these would be. These are the ones I missed being able to use. If any of these features do exist in VS and I just missed them, please do let me know in the comments!

• The biggest frustration was being unable to move changes to a separate changelist. I use this for local changes which should never be committed, and on this particular project there was a lot I needed to change in configuration files for local development. In VS I can’t find a good way to have local changes which won’t be committed, but this is very simple (and useful) in Rider.

• VS doesn’t have a UI for interactive rebase. I don’t use this a huge amount, but I use it enough that it’s really useful. Having the visual element gives me much more confidence that I’m doing the right thing given it can be a complex operation.

• VS doesn’t support copying the reference to a method - e.g. MyClass.MyMethod or MyNamespace.MyClass.MyMethod. Rider has very flexible functionality for copying references and you can set up a shortcut for it.

• When using GitHub Copilot in Edit mode, VS doesn’t seem to provide an option for rejecting all edits. Microsoft obviously have more confidence in the AI suggestions than JetBrains do!

Lastly, one major feature difference that didn’t affect the work I’ve been doing on this occasion, but has been huge on some projects I’ve worked on:

• VS can’t perform refactoring across both html and typescript files. When working with an angular app for example, this means something as simple as renaming a property in a typescript class is a breaking change if the class is used within a component template. You have to manually find all usages, which is tricky if the property name is not unique. In Rider, it’s a non-issue. You just use the refactoring tools to rename the property, same as you would in C# code.

It’s to be expected that I’m more aware of the features Rider has than whatever features VS has which are missing in Rider. Having said all that, there are 2 features which I liked in VS that Rider doesn’t have:

• It’s nice to switch solution from the solution explorer. As it happens, the project that I’m using VS for has several solutions within the same git repository, and it’s nice to have a dedicated UI for smoothly switching between them.

• Visual Studio can run apps using local IIS. It’s only fair to note that this is the reason I’m using Visual Studio for this particular project, as it’s the only IDE I know of which is capable of running an application which uses this setup. I guess I could develop and build the application in a different IDE, but to run it locally I believe Visual Studio is a requirement.

Quality of life differences

These are small differences which add up to a much more pleasant developer experience in Rider.

• It doesn’t seem possible to create a keyboard shortcut for extracting some code into a local variable! This is a really common refactoring that I use all the time, and I just assumed it would be supported. It’s possible by using the Quick Actions icon, which does have a keyboard shortcut, but it’s more friction than I expected.

• Both Visual Studio and Rider have a keyboard shortcut to select the current word (i.e. based on the position of the caret). However, only Rider allows you to repeat the shortcut to expand the selection. I use this a lot in Rider for selecting a coherent section of code, somewhere between a word and a line. This is useful for generics (e.g. GenericClass<Foo>), lambda expressions and hyphenated words. To make matters worse, selecting the current word doesn’t even work when multiline editing - VS removes all your cursors except one, and highlights the single word where that cursor is. In Rider all the words containing cursors are selected, and the multiple selections can be expanded as needed.

• When VS makes a method asynchronous, it updates the method name to have the Async suffix. That is what I would have done next, so it was nice to update the method signature and method name in the same action. However, it didn’t await the method in the calling code. (I can’t remember for sure what Rider does in this scenario.)

• VS doesn’t name private readonly fields with an underscore prefix when creating them from a constructor argument, which Rider does. This may be configurable, I haven’t needed it enough to be worth working it out, but I was surprised this isn’t the default behaviour as I thought it was a very common convention.

• VS does include the Inline Temporary Variable refactoring, but only makes it available from the declaration of the temporary variable, not the usage of it. Also, in the Quick Actions menu it’s the second option, with the first being to create a new local variable (which is pointless in the case of a temporary variable, as it just creates a second useless temporary variable). This means VS offers 2 refactorings, a useful one and a useless one, but it puts the useless one first. Also, it also doesn’t seem possible to map a keyboard shortcut to Inline a Temporary Variable.

• In VS it’s not possible to collapse a method from the end of the method, only from the beginning. This is the same for regions, the block of using statements at the top of a C# file, etc. For some reason the assumption is that you’ll only want to collapse a large block of text when scrolling down a file, but never when scrolling up.

• When you move a C# file to a different folder, VS can update the namespace in that file to match the folder structure. However, if you’ve moved multiple files it can’t update the namespace for a whole folder, leaving the developer to go through the files one at a time.

• When copying & pasting code, VS doesn’t seem to update the indentation to match the destination. I like that Rider sorts this out for me, but VS makes me manually fix the indentation.

Conclusion

VS is perfectly usable without Resharper, there are no fundamental problems which make it unreasonable to use for day-to-day development. I like some of the features which Rider has and VS doesn’t (and I probably don’t know what I’m missing if VS has any features which Rider doesn’t). I was surprised that refactoring was harder work in VS, I would have thought that was a fairly obvious place to have feature parity. There weren’t really any pleasant surprises in VS, so if there are any features that I would have liked then I didn’t discover them.