Why I Use JetBrains Rider for .NET Development

Authored by Emanuele Bartolesi for This is Learning.

Why I Use JetBrains Rider for .NET Development

Finding the ideal IDE for .NET development is rarely a straightforward journey. As .NET developers, we invest significant time in tooling, and any disruption – slow loading, awkward workflows, or missing features – can severely impact focus and flow. While Visual Studio has long dominated my daily tool statistics, JetBrains Rider has, in recent years, earned a permanent place on my machine, and for excellent reasons.

Rider is far more than just another editor. It's a modern, cross-platform IDE built from the ground up by the same team behind ReSharper. If you've ever envisioned a fast, resource-efficient, and deeply integrated development environment for .NET, Rider is likely already on your radar. My experience has shown that after the initial adjustment period, Rider subtly enhances the everyday .NET development experience – often in ways you only truly appreciate when you revert to other tools.

As the screenshot above illustrates, Visual Studio is no longer installed on my machine.

Why I Chose Rider Over Visual Studio

My journey with Rider began with curiosity but quickly evolved into a deep appreciation for its ability to eliminate numerous pain points. The first striking aspect was how effortlessly Rider operates across all my machines, irrespective of the operating system. I frequently switch between Windows and Mac, and the seamless portability of my IDE and settings is invaluable. There are no workarounds, no feature gaps, and no "missing" editor windows.

I previously used VS Code as my primary .NET environment, but I found myself missing a significant number of features. While I genuinely admire VS Code (I even have a tattoo of its logo), I concluded it isn't the optimal tool for comprehensive .NET development.

Performance is another area where Rider truly excels. It opens even massive solutions quickly and rarely falters, even during complex refactorings or extensive code analysis on large codebases. The UI is modern and uncluttered, yet highly customizable. Shortcuts and navigation are easily adjustable, allowing you to rapidly develop a rhythm where you can effortlessly navigate files, definitions, and references without needing to reach for the mouse.

However, what truly won me over was the depth of its built-in tooling. Rider inherently includes ReSharper-level code inspections, refactorings, and quick-fixes. There’s no need to install additional plugins or endure the potential lag that can sometimes accompany layering extensions in Visual Studio. Integrated Git support (though I often combine it with GitKraken, GitHub Desktop, and the command line), a robust database explorer, and even a built-in HTTP client are all available out-of-the-box.

For this reason, I still retain Postman on my machine, but I prioritize using Rider's internal HTTP client whenever possible. It allows me to save HTTP files directly within the solution, making them part of the source code and accessible to everyone on the project.

Living With Rider Day to Day

Switching IDEs represents a significant commitment, and I was initially skeptical about abandoning years of muscle memory from Visual Studio.

Initially, I had both VS and Rider installed side-by-side, but I often defaulted to Visual Studio due to reluctance to learn new habits. It wasn't until I acquired a new laptop and deliberately installed only VS Code and Rider that I compelled myself to fully embrace it. No excuses.

After the first week, Rider’s workflow began to feel entirely natural. Solution management is effortless; I can open .NET Core, ASP.NET, and Windows Forms projects within the same window. Multi-targeted projects function seamlessly. Git operations and branching are tightly integrated. The built-in terminal minimizes context switching, and the task runner enables automation of everything from builds to test runs with just a few keystrokes.

Debugging is fast and reliable – setting breakpoints, inspecting variables, attaching to processes, and even editing code while debugging all feel responsive. Navigating large codebases is more fluid, thanks to instant "Go to Definition" and comprehensive symbol search features. Code inspections and suggestions are consistently present, yet never intrusive.

Rider feels purposefully designed for developers who prioritize coding over configuration. Dark mode, custom themes, and adaptable keymaps allow you to tailor the environment to your preferences with minimal effort.

Currently, I use Rider's default Dark theme. To maintain a consistent experience, I also found and applied a port of this theme for VS Code.

5 Hidden Gems in Rider

Beyond its prominent features, Rider contains several tools that can profoundly transform your workflow, often going unnoticed until you discover them.

First, Rider’s dynamic code analysis runs continuously in the background, identifying potential bugs, code smells, and even subtle style violations. The true power lies in its instant quick-fixes: a single keyboard shortcut (Alt+Enter) allows Rider to reformat, refactor, or even rewrite problematic code, all without interrupting your concentration.

I sometimes disable this option when working on my laptop while commuting or away from my desk to conserve battery. It's very easy to toggle on and off directly from the File menu.

Navigation is another quiet superpower. The "Search Everywhere" window, invoked with Shift+Shift, provides a single point of access for files, classes, symbols, settings, and even menu commands. Combined with highly customizable keymaps and actions, it facilitates seamless project navigation without ever needing to use the mouse.

For those who prioritize code consistency, Rider’s robust integration with .editorconfig files is exceptional. The IDE automatically enforces formatting and style rules across your project and visually highlights where your code deviates from team standards. The built-in visual editor simplifies tweaking rules, allowing you to catch issues proactively before they reach code review.

I frequently use a .editorconfig file shared by my friend, Marco Minerva, moving it between projects constantly.

For developers who frequently interact with web APIs, Rider’s HTTP client is a modest yet powerful addition. It enables you to create .http files directly within your solution, send requests, inspect responses, and even generate C# HTTP client code – all without leaving the IDE or resorting to external tools like Postman.

Finally, Rider’s integrated database explorer often eliminates the need for a separate SQL tool for most data-related tasks. You can connect to major databases, run queries, and even preview LINQ queries mapped to your schema – all from within your solution. As someone not truly an expert in Database and Entity Framework, I particularly value this integration.

GitHub Copilot Integration

One of the most compelling recent developments for Rider is its tight integration with GitHub Copilot. As you type, Copilot presents context-aware suggestions, sometimes completing entire methods or generating boilerplate code from just a comment or a function signature.

What makes this especially valuable is how seamlessly Copilot integrates with Rider’s existing completion system. Suggestions appear inline, can be accepted or cycled through with familiar shortcuts, and function across all supported languages – including C#, JavaScript, TypeScript, and Razor files. This ensures you receive AI assistance not just for backend code, but also for front-end development, tests, and even scripting tasks.

For me, Copilot in Rider is more than a novelty; it's a genuine productivity enhancer. It helps me prototype faster, learn new APIs in context, and minimize repetitive coding.

(I plan to write a separate blog post dedicated to this specific topic.)

Drawbacks and Considerations

No tool is perfect, and Rider is no exception. The most apparent barrier for many is its cost: Rider requires a commercial license. However, for hobbyists or open-source developers, a free version with all features enabled is available!

Extension support is another factor to consider. While Rider’s plugin ecosystem is robust and continually expanding, certain Visual Studio extensions and integrations have not yet made the transition. If your workflow heavily depends on very specific or niche tooling, it's advisable to verify compatibility before making the switch.

The UI will require some acclimatization if you're transitioning from Visual Studio. Some menus are arranged differently, and not all wizards or designers are present. If you rely on Windows-specific features, particularly for legacy .NET workloads or advanced Azure integrations, you might find Rider to be less comprehensive in those areas.

Finally, in larger organizations, the choice of IDE might not be entirely yours. Some teams or companies standardize on Visual Studio, which could lead to Rider's use being discouraged or unsupported in such environments.

---

🙋‍♂️ Hey, I'm Emanuele — you might know me online as Kasuken. 👨‍💻 Senior Cloud Engineer | Microsoft MVP (12x) | GitHub Star (4x) 🛠️ I build things with .NET, Azure, AI, and GitHub. 🌈 Turning code into 🦖 and 🦄 — one commit at a time. 🚀 If you're into .NET, GitHub, DevOps, or just cool side projects, feel free to connect with me on LinkedIn. P.S. I break things so you don’t have to. 😉