JetBrains’ Rider: First Impressions

Jack Finlay - January 02, 2018


I am a lover of Visual Studio Code, with its power and flexibility, but have had further wanting for a C# IDE on Mac. I decided I would try out JetBrains’ C# IDE: Rider. I’m now so glad I did.


Setup of Rider was super easy. I installed version 2017.2 - As with most macOS software, it was a simple drag and drop of the application into the applications folder. When you open Rider for the first time, a simple wizard guides you through some basic setup. There are options to include certain frameworks and languages, such as Unity, and F#; Options for version control, such as enabling/disabling various types such as Mercurial, Subversion, Git, and others — I opted to just enable Git and GitHub integrations as that’s how I work; There are also some options regarding UI and UX, which were impressive.

Customisation was a breeze. Customisation was a breeze.


The first thought that came to mind when I opened Rider for the first time was simply: wow. Rider shares an aesthetic with JetBrains’ other IDE offerings, such as IntelliJ IDEA. But that doesn’t mean it’s all just a cookie cutter offering with some language packs. No, this has definitely been catered to the .NET ecosystem. There’s a NuGet package manager; a test-runner that automatically picks up the test platform and scaffolding, making it possible to jump straight into running your tests; a terminal that matches your current system terminal — mine being an Oh-my-zsh implementation, with git status indicators built in; and all the usual code and file navigation tools you would expect, with special attention given to .sln and .csproj files: these are detected and recognised by rider as solution and project files respectively.

Rider in action. Rider in action.

During setup there are a few UI/UX settings available. I opted for the “Darcula” theme with Visual Studio key bindings and Visual Studio dark theme syntax highlighting. I think the syntax highlighting in Visual Studio Code is a little different, and would prefer to use that scheme if it were available, as that’s what I’m used to now.


The sheer performance and speed of Rider is absolutely astonishing. When compared to Visual Studio, and I’m talking the full-blown Windows IDE suite here, Rider knocks it straight out of the park. You can count the seconds it takes to load on one hand, then take a few fingers away. This is brilliant when compared to Visual Studio. Although Rider becomes usable almost instantly, the parts inherited from ReShaper such as the code-quality and error analysis do take a few more seconds to load in after opening a project as it appears to re-analyse the project from scratch.

Errors, errors everywhere

The second thing I noticed is that once Rider had taken a few seconds to analyse my project, there were just errors popping up everywhere. It turns out that the project I had opened , Jsonize, was targeting a version of the .NET framework. Being on a Mac, this obviously wasn’t going to be able to check anything at all against the framework. Luckily Rider has got your back, with a nice message in the event log that lets you know where and how to get the Mono framework installed. Once I followed the instructions and installed Mono, everything worked great. The only problems left now were from my own code!

I heard you like hints…

The next thing you’ll notice is all the hints that the ReSharper parts of Rider provide about your code. Now these can range from simple things that make sense, like making some strings into constants, to the suggestion that anything that isn’t a basic type should be a var. Now, I’m not a fan of the var keyword; To me it goes against the whole idea of static typing, especially when I know what the return type should be, so I turned that hint off. Besides these hints, there are a whole bunch more that you can configure to your liking.

Tuning some of the over-eager code style hints. Tuning some of the over-eager code style hints.

Testing, testing, 1, 2, 3.

As mentioned earlier, there is a test-runner built right into Rider. This provides a great way to monitor and run tests directly from the testing window. You no longer have to type `dotnet test` at the terminal to run your tests. According to JetBrains, there is support for MSTest, xUnit, and NUnit testing frameworks. I had no trouble at all getting Rider to pick up the xUnit tests in my projects I tried it on — it simply worked straight out of the box, so to speak. One gripe I have with the test-runner is that the output panel is not the standard console, it doesn’t appear to pick up any of the `Console.WriteLine` statements I had in my test code (I needed to see the actual output to tune the tests). To see these I had to use the built in terminal to run my tests.

Edit: The above is incorrect, you shouldn’t actually be using Console.WriteLine() with xUnit, rather you should be using ITestOutputHelper instead. See the official documentation for details.

The test runner console. The test runner console.

Closing thoughts

It takes a lot to beat out Visual Studio Code in terms of the feature-set and optimisations provided for programming in C# on a Mac, but JetBrains’ Rider has certainly done so. It feels great to be using a fully-fledged IDE again. The power of having all your tools in one place helps with productivity, and the hints provided by the ReSharper engine make writing great code a breeze. Not only does Rider look good, it is also great to use from a user experience perspective. I’ll be sticking to Rider for now until my trial is up, and will provide further review then.

Feel free to email me, tweet at me, or scream into the ether, whatever suits. You do you.

Jack Finlay

Jack Finlay - Software Engineer in Melbourne, Australia. Exploring the writing process and developing my skills through the occasional article on life as a programmer. Follow me on Twitter for updates.