Microsoft’s Visual Studio has been around for more than twenty years, since 1997, and has long been the only viable solution to program .NET applications. About three years ago, JetBrains entered this market with the 2017.1 release of Rider. It offers support for .NET Core, Unity and Xamarin. If you are working in one of these areas, you may wonder if it’s now worth it to switch to a new IDE and to give up on Visual Studio.

Understandably, developers can be wary of switching their development environment. It means giving up what you’re comfortable and productive with, things you could lose at least temporarily when trying something new. Plus, you don’t even know if the new IDE meets all the requirements you have for your daily work.

If you search the web, you will already find several comparisons between Rider and Visual Studio (e.g. here and here). Also, the JetBrains homepage includes a Rider vs. Visual Studio feature comparison. The latter may obviously be biased towards Rider, but what these comparisons have in common is that they give quite a long and detailed list of (often minor) differences between the two IDEs.

But ask yourself: does it really matter for example how nice the git plugin of an IDE is? Or could you just as easily choose one of the many great established solutions, like SourceTree or the Git Bash? And is there really a noticeable difference if your code generation saves you some typing? This is why in this blog post I want to focus on only the select few aspects that really make a difference.

In the end you are hopefully able to decide if it’s worth the trouble to abandon the IDE you’re used to and to switch from Visual Studio to Rider.

One big issue when starting to use Rider is that you will immediately notice that it surpasses Visual Studio in terms of performance.

Why does performance really matter? Simply, because if the IDE gets stuck and stops you from working for too long, you will lose focus and may switch your attention to other things, like browsing the web. Focus, being in a state of flow, or “being in the zone” is the mental state where a developer is the most productive. According to Tom de Marco’s and Tim Lister’s book Peopleware it will take a developer on average 15 minutes to get back into flow once it is lost. So, not only will your IDE stop you from working during the time it is stuck, but it will also increase the overall working time that you have to spend to finish your development task.

To give a quick comparison between two IDEs, I started both on my machine and rebuilt the solution containing an ASP.NET Core project with 90 subprojects. I used ReSharper as a plugin to Visual Studio to achieve more or less feature parity. Given the prevalence of ReShaper I think this is a fair comparison. Visual Studio VS 2019 took close to three minutes to finish, Rider 2020 about 2:20 minutes.

This by itself isn’t especially noteworthy. However, when using Rider I only had to wait about 20 seconds until I could start interacting with the IDE. Visual Studio on the other hand was frozen almost all the time, I was only able to open files or write code once the build process was finished.

The same goes for things like switching between different git branches. I tried to change branches with different .NET Core versions on them, which requires the IDE to rebuild and reindex the solution, an operation that takes several minutes in my case. Again, with Rider the process is pretty fluent with only a few lags here and there, but Visual Studio is frozen almost the entire time.

In summary: Rider lets you work without big interruptions, Visual Studio threatens your focus to get lost. Clear advantage for Rider.

A big reason we use IDEs is to avoid errors. This is done on one hand by showing syntax errors and other compilation errors immediately, we don’t have to wait until an exception occurs while running the application. On the other hand modern IDEs include code analysis, which detects potential errors and code smells during design time.

To emphasize this point, code analysis can be a huge deal, especially in large software projects. If you ever found yourself in a project where the same easily avoidable bugs happened over and over (say, null pointer exceptions or incorrect type casts), you will know that static code analysis can make your life a lot easier. Reducing the time spent on code reviews is a side effect of this. You don’t have to waste time to point out code issues which follow simple rules. A code review shouldn’t consist of criticizing unused imports or violated naming conventions. That’s something an algorithm can find for you much faster and more reliably.

Rider prevails here. Visual Studio has about 440 code analysis rules against Rider’s 1400. Obviously, numbers don’t tell you everything, but if you use Visual Studio, you will see that it misses out on elementary things. Possible NullReference-Exceptions should always be handled by your code. If two different types don’t share a common ancestor, then trying to cast between the two is clearly a bug. Unused code unnecessarily clutters your code and makes it harder to maintain. These are all examples of issues Visual Studio doesn’t detect (or detects only partly in the case of unused code).

You can circumvent this by using ReSharper on top of Visual Studio to get an almost as strong code analysis as Rider, but this will come with the performance losses mentioned in the previous section.

A big challenge when you’re a newcomer to an established market, like in the case of JetBrains entering a market dominated by Microsoft, is that you will not have as a large community behind you in the beginning. That is a problem in the case of plugins, which are developed not by Microsoft itself, but by the community.

A project I was part of was using SpecFlow to write Behavior Driven Tests. For backend development this isn’t a very common use case. A plugin existed for Visual Studio, but not for Rider. In the end, running the tests was only possible using workarounds stitched together from diverse blog posts on the internet. Generating the tests methods however was not possible, and had to either be done manually or by still using Visual Studio on the side. Not a perfect solution.

But also the lacking maturity of Rider means it does not include all the features that Visual Studio does. For example, developing and debugging directly on IIS is not possible on Rider. This once more isn’t a very common use case, because IIS Express exists specifically as a developer version of IIS. It is pretty rare that you need specific features from IIS in your development process. But still, in some circumstances it might block you.

There is a wide variety of features that Visual Studio offers and an even wider variety of plugins, so it doesn’t make sense listing them all here. To judge if this does impact you, my personal solution would be this: check if your current project right now needs any specific features or plugins only available for Visual Studio. If not, you’re free to migrate to Rider. Don’t focus on impediments you might have in the future. Requirements often change, so over-preparing isn’t helpful. Also, thinking in simple probabilities tells us that the features you need are more likely common features rather than uncommon ones. And if they are common, then it’s likely that Riders offers what you need, either now or it will in the near future.

Nevertheless, to sum up: Visual Studio is just more advanced in the features that it offers. Leaving those behind is not possible for every developer, making this a clear downside of Rider.

Other big issues when choosing an IDE are how much bugs it has and how much it will cost. Regarding bugs, it’s nearly impossible to tell which one has fewer in it, since you would first have to work with every possible feature of the IDE to be able to evaluate their impact. From my personal experience though, I found relatively severe ones in both.

One that I remember for Visual Studio is this one:

I had this bug just this year, in 2021. The application couldn’t be started, but there weren’t any processes running which I could have terminated as the error message would imply. Because the obvious solutions didn’t work, it took me several hours to finally find out the underlying cause. Looking at the link from StackOverflow documenting this bug, you will see the question is already six years old, from 2014. The argument that increasing age ironed out most bugs of Visual Studio does not apply.

The same goes for Rider. I recall a bug that prevented me from starting my application in IIS Express. Only a multi-step solution, again from StackOverflow helped to solve this issue after a couple of hours of trying.

To sum up, with Visual Studio we have a larger legacy code base which can hide errors, but Rider is lacking in maturity and not everything has been as thoroughly tested. Neither of them is a clear winner here.

What might be a final criterion to choose an IDE is its price. At the time of this writing Rider comes for about 35€ per month, Visual Studio Professional is $45 (about 38€). Not a huge gap. Differences in your productivity should have a much bigger impact than the difference in price of these two.

So, which IDE should you use? As always the answer is: it depends. If you’re sure you need the features or plugins that Visual Studio has to offer, or you still have to keep developing in the .NET Framework, then Visual Studio really is the only option.

However, if you’re a .NET Core, Xamarin or Unity developer tired with the slow performance and mediocre code analysis of Visual Studio, you should give Rider a try. Plus: switching to Rider is easy. You get to keep all your old shortcuts if you want to, and if you already own ReSharper you can upgrade to JetBrains’ dotUltimate for only a small increase in price.