JetBrains 2026.1: ReSharper Breaks Out of Visual Studio, Rider Gets an ASM Viewer

For years, the choice between JetBrains and the rest of the .NET tooling world came down to a fairly clean split: ReSharper lived inside Visual Studio, Rider was the standalone IDE, and if you preferred VS Code you were on your own. The 2026.1 releases, which shipped on 30 March, blur those lines significantly. ReSharper now runs as a VS Code extension. Rider can open a lone .cs file and run it without a project. And both products pick up features that used to require separate profiling tools or third-party extensions.

This is a substantial release cycle. Rather than cataloguing every checkbox, let us focus on the changes that will actually shift how you work.

ReSharper arrives in VS Code

This is the headline. After a year in public preview, ReSharper is now officially available as an extension for Visual Studio Code, Cursor, and Google Antigravity. It is not a stripped-down port — the extension ships with solution-wide code analysis, refactorings, navigation (including decompilation), and integrated unit testing for NUnit, xUnit.net, and MSTest.

The language coverage at launch is C#, Razor, Blazor, and XAML. You get real-time inspections, context-aware completion, auto-imports, live templates, and a Solution Explorer for managing projects, NuGet packages, and source generators. In practical terms, it is the ReSharper analysis engine running out-of-process and surfacing results through the VS Code extension API.

How it compares to C# Dev Kit

The obvious question: why would you choose this over C# Dev Kit? The short answer is analysis depth. ReSharper's inspection catalogue is significantly larger, its refactoring support covers more edge cases (solution-wide renames that touch XAML bindings, for instance), and you get decompilation-backed navigation out of the box. If you have ever been frustrated by C# Dev Kit's limited refactoring options or its occasional inability to resolve cross-project references, this is aimed squarely at you.

The trade-off is licensing. ReSharper for VS Code is free for non-commercial use — learning, hobby projects, open-source contributions, and content creation all qualify. Commercial use requires a ReSharper, dotUltimate, or All Products Pack subscription.

Installation

Installation is straightforward — search for "ReSharper" in the VS Code Extensions view, or install from the Open VSX Registry if you are using a compatible editor like Cursor. The extension picks up your existing .editorconfig and ReSharper settings files, so your team's code style rules carry over without additional configuration.

Built-in performance monitoring

ReSharper 2026.1 introduces a Monitoring tool window that tracks CPU usage, memory allocation, and other runtime metrics while your application runs or during debugging. This consolidates capabilities that were previously scattered across Dynamic Program Analysis (DPA) and the standalone profiling tools into a single, always-available panel.

The tool window surfaces automated insights — it flags potential performance issues as they occur rather than requiring you to set up a profiling session after the fact. Think of it as a lightweight profiler that runs alongside your application without the ceremony of attaching a full dotTrace session.

This feature is exclusive to dotUltimate subscribers. If you are on a standalone ReSharper licence, you will not see the Monitoring tool window.

Out-of-Process mode grows up

Speaking of OOP mode: this release addresses over 70 issues affecting navigation, UI interactions, unit testing sessions, and solution state synchronisation. If you tried OOP mode in 2025.3 and hit rough edges — tests not discovering, Find Usages returning stale results, or the occasional UI freeze — it is worth revisiting.

The runtime has also been upgraded to .NET 10, which brings its own performance improvements to the ReSharper host process. The cumulative effect is noticeably faster indexing and more responsive code completion, particularly in larger solutions.

C# language improvements across both products

Both ReSharper and Rider 2026.1 share the same underlying analysis engine, so the C# improvements apply everywhere:

Extension member support has been significantly improved. Navigation, Find Usages, and refactorings now handle extension members correctly, including the newer extension blocks introduced in C# 14. Import quick-fixes work properly for extension members too — no more manually adding using directives for extension types.

New inspections catch several real-world mistakes:

• Short-lived HttpClient instances — detects new HttpClient() usage in hot paths where you should be using IHttpClientFactory instead. Socket exhaustion from disposable HttpClient instances remains one of the most common production issues in .NET services, so this inspection earns its keep.
• Incorrect ImmutableArray<T> initialisation — catches the subtle bug where you use default(ImmutableArray<T>) and then call methods on it, which throws a NullReferenceException because the underlying array is null.
• Accessor ordering — flags properties where the get and set accessors do not follow your configured ordering convention.

Early C# preview support includes collection expression arguments and the [ExtendedLayout] attribute. If you are tracking the C# 15 language proposals, you can start experimenting with these in both Rider and ReSharper without waiting for a full language release.

Additionally, string styling is now configurable — you can enforce either string.Empty or "" as your team's preferred empty-string representation, with quick-fixes to convert between them.

Rider: file-based C# programs

Rider 2026.1 can now open, run, and debug standalone .cs files without a project file. This aligns with the file-based programs feature introduced in the .NET 10 SDK, where a single file with top-level statements is a complete, runnable program.

#:package Spectre.Console@0.49.*

using Spectre.Console;

AnsiConsole.MarkupLine("[bold green]Hello[/] from a file-based program!");

Rider's editor recognises top-level statements, #! shebangs, and the #: directives (#:package, #:sdk) that the .NET SDK uses for dependency resolution. Code completion, navigation, and debugging all work as expected — you get the full Rider experience without the overhead of a .csproj.

This is genuinely useful for prototyping. Instead of creating a throwaway console project, adding a NuGet reference, writing your code, and then deleting the project when you are done, you can open a single file and start writing. It is also a natural fit for scripting scenarios where you want the convenience of C# with the simplicity of a script file.

Rider: the ASM Viewer

This one is for the performance-minded. Rider 2026.1 ships a new ASM Viewer tool window that displays the native disassembly generated from your C# code. You can inspect output from the JIT compiler, ReadyToRun, and NativeAOT — all without leaving the IDE.

The viewer supports configurable compiler options including tiered compilation and profile-guided optimisation (PGO). More practically, it includes a snapshot and diff view: write your code, take a snapshot of the generated assembly, make a change, and compare the two side by side.

If you have ever used SharpLab or BenchmarkDotNet's [DisassemblyDiagnoser] to check whether the JIT is devirtualising a call or vectorising a loop, the ASM Viewer brings that workflow directly into your editor. Select a method, open the viewer, and see the machine instructions the runtime actually produces.

Rider: the ACP Registry

Rider 2026.1 introduces the ACP (Agent Connectivity Protocol) Registry, which lets you discover and install AI coding agents directly from the IDE. The registry includes Junie (JetBrains' own agent), Claude, Codex, GitHub Copilot, and Cursor, among others.

The practical benefit is that you are no longer locked into a single AI provider. You can install multiple agents, switch between them depending on the task, and they all integrate with Rider's existing editor and terminal. Combined with MCP server support for AI chat with native database access, this positions Rider as an agent-agnostic host rather than a walled garden.

Other notable additions in Rider

• NuGet Package Manager Console (preview): PowerShell-based NuGet and EF Core commands now run inside Rider. If you have muscle memory for Update-Package and Add-Migration, you no longer need to switch to a terminal.
• Azure DevOps plugin: Browse and clone repositories directly from Rider without leaving the IDE.
• MAUI iOS development on Windows: Automatic environment verification and configuration for iOS builds, reducing the setup friction that has historically made MAUI development on Windows painful.
• Unity Profiler integration: Redesigned to let you open profiler snapshots directly in Rider, analyse frames and call stacks, and navigate to source code from performance data.
• F# debugging improvements: Smart Step Into and improved async workflow navigation make debugging F# code significantly less frustrating.

Common pitfalls

Assuming ReSharper for VS Code replaces Rider. It does not. The VS Code extension gives you analysis, refactoring, and navigation, but Rider's integrated debugger, database tools, profiler, Docker support, and game development features are not part of the package. If you need a full IDE, Rider is still the answer. The VS Code extension is for developers who prefer VS Code's lightweight editing model but want deeper C# analysis than C# Dev Kit provides.

Forgetting to check OOP mode compatibility. The Monitoring tool window and a handful of other features are not yet available in OOP mode. If you switched to OOP mode for stability (which was the right call), verify that any new feature you rely on actually works there before restructuring your workflow.

Treating the ASM Viewer as a profiler. The ASM Viewer shows you what instructions the compiler generated, not how fast they run. A method with fewer instructions is not necessarily faster — branch prediction, cache locality, and memory access patterns all matter. Use the ASM Viewer to verify that the JIT is generating what you expect, then use BenchmarkDotNet to confirm the performance impact.

Ignoring the new HttpClient inspection. If your codebase predates .NET Core 2.1 patterns, you almost certainly have new HttpClient() calls scattered through service classes. The new inspection will light up like a Christmas tree. Resist the urge to suppress it — migrate to IHttpClientFactory instead. Your operations team will thank you when socket exhaustion stops taking down production at 2 AM.

Summary

The 2026.1 releases represent a genuine expansion of the JetBrains .NET tooling surface:

• ReSharper for VS Code brings full code analysis, refactoring, and navigation to VS Code, Cursor, and compatible editors, with free non-commercial licensing
• Built-in Monitoring consolidates runtime performance tracking into ReSharper without requiring separate profiling tools (dotUltimate only)
• 70+ OOP fixes make Out-of-Process mode significantly more reliable for daily use
• File-based C# programs in Rider let you run standalone .cs files with full IDE support
• The ASM Viewer puts native disassembly inspection directly in Rider's editor with diff support
• The ACP Registry makes Rider an agent-agnostic host for multiple AI coding assistants
• New C# inspections catch HttpClient misuse, ImmutableArray<T> bugs, and extension member issues across both products

Both products are available now. If you have been on the 2025.3 line, the upgrade is straightforward — your settings and plugins carry over. If you have been waiting for ReSharper's VS Code extension to leave preview, this is the release to try.