What are the main IDEs and editors for .NET development, and how do Visual Studio, Visual Studio Code and JetBrains Rider differ?

How I would answer this in an interview

"When talking about .NET tooling, the main choices are Visual Studio, Visual Studio Code, and JetBrains Rider. Visual Studio is a Windows-only full IDE with comprehensive designers, whereas VS Code is a lightweight cross-platform editor that, with the C# extension and C# Dev Kit, provides a robust Roslyn language server and debugging. Rider is a cross-platform IDE built on the ReSharper engine, well-known for deep refactoring.

Crucially, none of them own the build; all three drive the same .NET SDK and MSBuild, so a project builds identically on the command line regardless of the editor. A key trade-off is licensing and resource overhead: Visual Studio and Rider consume more memory and have strict commercial licensing limits, whereas VS Code is lightweight but requires attention to licensing compliance.

Editor choice is personal while build behaviour is not, so I choose based on the operating system, workload, and team standards while keeping the .NET SDK and .editorconfig as our source of truth."

How I would answer this in an interview

"For .NET development, the main choices are Visual Studio, Visual Studio Code, and JetBrains Rider. Visual Studio is a Windows-only full IDE with comprehensive designers and profilers. VS Code is a lightweight cross-platform editor that, with the C# extension and C# Dev Kit, provides a robust Roslyn language server, Solution Explorer, and debugging. Rider is a cross-platform JetBrains IDE built on the ReSharper engine, well-known for deep refactoring and analysis. Crucially, none of them own the build; all three drive the same .NET SDK and MSBuild, so a project builds identically on the command line regardless of the editor. A key trade-off is licensing and resource overhead: Visual Studio and Rider consume more memory and have strict commercial licensing limits, whereas VS Code is lightweight and extensible but requires attention to extension trust and C# Dev Kit licensing compliance. In practice, I choose based on the operating system, workload—such as WPF designers—and team standards."

Licensing in more detail

• Visual Studio Community is free for individual developers, open-source projects, academic research, education and classroom use, and for non-enterprise organisations with up to five users. An "enterprise" (more than 250 PCs or more than US$1 million in annual revenue) needs Professional or Enterprise subscriptions for commercial work.
• C# Dev Kit uses the same terms as Visual Studio Community, so an organisation outside those limits needs a qualifying Visual Studio Professional or Enterprise subscription (or GitHub Codespaces) even if its developers only use VS Code. The VS Code editor and the C# extension themselves are free.
• Rider is free for non-commercial use; commercial work needs a paid JetBrains licence.

What they share

None of them owns the build. Each one asks the .NET SDK (chosen by global.json or the latest installed) to evaluate the project with MSBuild, then compiles with the same Roslyn compiler. The CLI tools are also shared: dotnet test, dotnet format and dotnet ef behave the same whichever editor launched them, because the IDEs call the same SDK. That is why dotnet build in CI should produce the same result as pressing F5. If something only works inside one IDE, that is a bug in the project setup, not a feature.

How I choose

• Windows desktop work (WinForms, WPF) or heavy Azure tooling: Visual Studio, because its designers are the most complete.
• macOS or Linux developers: Rider or VS Code. Visual Studio for Mac was retired on 31 August 2024.
• Polyglot or container-first teams: VS Code, because the same editor handles C#, TypeScript, Bicep and YAML, and Dev Containers give a reproducible environment.
• Large legacy solutions that need heavy refactoring: Rider (or Visual Studio with ReSharper).
• Budget and compliance: check licensing before rolling out any of them across a company.

Production example

On a team building an ASP.NET Core API hosted in Azure Australia East, Windows developers used Visual Studio, two Mac developers used Rider, and the platform engineer used VS Code for Bicep and pipelines. Because the repository pinned the SDK in global.json, shared style through .editorconfig, and CI ran dotnet build and dotnet test, nobody's editor choice affected the output.

1. Every IDE is three layers

Knowing which layer misbehaves is most of the skill when an editor acts up.

            +---------------+  +----------------------+  +-----------------+
 Editor UI  | Visual Studio |  | VS Code + C# Dev Kit |  | JetBrains Rider |
            +-------+-------+  +----------+-----------+  +--------+--------+
 Language   Roslyn workspace      Roslyn language server    ReSharper backend
 engine     (main process plus    (separate process,        (separate .NET process;
            helper processes)     Language Server Protocol) IntelliJ front end)
                    +-----------------------+---------------------------+
                                            v
               .NET SDK (selected via global.json) + MSBuild evaluation
                                            v
                      restore -> build -> run / test / publish

2. How each language engine works

• Visual Studio hosts Roslyn in-process for the editor and moves heavier work (parts of code analysis, some language services, the test platform) into helper processes. Since Visual Studio 2022 the main process is 64-bit, so very large solutions no longer hit the old 4 GB memory ceiling.
• VS Code starts the Roslyn language server as a separate process and talks to it over the Language Server Protocol (JSON-RPC). If the server crashes, the editor keeps working and the server restarts. The C# output pane shows what it is doing.
• Rider runs the ReSharper engine as a separate .NET backend process, with an IntelliJ front end that runs on the JVM. The two talk over JetBrains' own protocol. Rider also loads the Roslyn analysers and source generators the project references, so analyser warnings match the other IDEs.

All three read projects the same way: they ask MSBuild to evaluate each project and run a design-time build (a partial build that lists source files, references, analysers and compiler options without compiling). That is why a failed restore or a missing SDK shows up as broken IntelliSense in every editor.

3. Debuggers

All three use the runtime's debugging interfaces, so breakpoints, stepping and variable inspection work the same way in principle; the differences are in the tool windows around them.

4. Feature comparison for .NET 10 work

5. Licensing decision table

The VS Code editor and the C# extension themselves are free for everyone; C# Dev Kit follows Visual Studio Community's terms.

6. Performance on large solutions

• Hundreds of projects multiply design-time builds. Visual Studio's solution filters (.slnf) load a subset; Rider and VS Code can also open part of a repo.
• Analysers and source generators run in the IDE as well as the build. One slow generator makes typing slow in every editor.
• Full-solution analysis (Visual Studio) and solution-wide analysis (Rider) find more problems but use much more memory; turn them on deliberately.

7. Security

Extensions and plugins run with your user's privileges and can read source code and credentials. Install them only from publishers you trust, keep them updated, and use VS Code's Workspace Trust (Restricted Mode) when opening an unfamiliar repository, because tasks.json, launch configurations and some extensions can execute code from the workspace.

8. .NET 11 awareness

.NET 11 previews can be tried in all three tools once their preview SDK support lands. Keep production projects on .NET 10 LTS and pin the SDK with global.json, so installing a preview doesn't change your build.

9. Try it yourself

1. Run dotnet new console -n ToolingDemo -f net10.0 and replace Program.cs with the code example.
2. Open the folder in two different editors and run it from each.
3. Run dotnet run from a terminal and confirm the output is identical.
4. Break the project on purpose (add a PackageReference to a package that doesn't exist) and watch how each editor reports the failed restore.
5. Delete bin/ and obj/, build from one editor, and look at the files produced: they are the same SDK outputs whichever editor you used.