When JetBrains shipped ReSharper for VS Code in March, the reaction from .NET developers was a mix of genuine excitement and a very loud "but where's the debugger?" The extension delivered code analysis, refactoring, navigation, and unit testing — all powered by the same engine that has run inside Visual Studio for two decades — but you still had to switch tools the moment you needed to hit a breakpoint. That gap closed on 13 July with ReSharper 2026.2, which ships a full debugger built on the same core engine as JetBrains Rider.

The timing is not accidental. Microsoft's decision to restrict C# Dev Kit to genuine Visual Studio Code installations left developers on Cursor, Kiro, Google Antigravity, and Devin Desktop without any official .NET debugging story. ReSharper 2026.2 fills that vacuum entirely. As of this release, it is the most complete .NET development extension available on editors that are not named Visual Studio.

The debugger: what actually shipped

The ReSharper debugger is not a lightweight wrapper around an existing debug adapter. It uses the same debugging engine that powers Rider, adapted to communicate through VS Code's Debug Adapter Protocol (DAP). The practical effect is that you get Rider-grade debugging in any editor that speaks DAP.

Breakpoints

The basics are covered: set, enable, disable, and remove breakpoints from the editor gutter. But the implementation goes beyond simple line breakpoints. You get conditional breakpoints (break only when an expression evaluates to true), hit count breakpoints (break on the Nth hit), dependent breakpoints (break only after another breakpoint has been hit), and logpoints (log a message to the debug console without pausing execution).

OrderService.cs
public async Task<OrderResult> ProcessOrderAsync(Order order)
{
    // Set a conditional breakpoint here: order.Total > 1000m
    var discount = await _discountEngine.CalculateAsync(order);

    // A logpoint here prints: "Discount for {order.Id}: {discount.Amount}"
    // without pausing execution — useful for tracing production-like flows
    order.ApplyDiscount(discount);

    return await _repository.SaveAsync(order);
}

Variable inspection and watch expressions

The VS Code Debug View shows local variables, watched expressions, and the full call stack. You can expand complex objects, inspect collection contents, and evaluate arbitrary expressions against the current execution context. If you have used Rider's debugger, the data is the same — the presentation just follows VS Code's native debug UI conventions.

Stepping and execution control

Step Over, Step Into, and Step Out all work as expected through the standard DAP protocol. You can also launch new debugging sessions or attach to running processes, which covers the two primary workflows: starting your application under the debugger, and connecting to something that is already running.

Unit test debugging

This was a pain point in 2026.1. You could run tests, but you could not debug them. Now you can set breakpoints inside test methods and run them under the debugger directly from the editor. The extension supports NUnit, xUnit.net, and MSTest — the same test frameworks it already knew how to discover and execute.

OrderServiceTests.cs
[Test]
public async Task ProcessOrder_WithLargeDiscount_CapsAtMaximum()
{
    var service = new OrderService(_mockDiscountEngine, _mockRepository);
    var order = new Order { Total = 5000m };

    // Set a breakpoint here to inspect the discount calculation
    var result = await service.ProcessOrderAsync(order);

    Assert.That(result.FinalTotal, Is.GreaterThan(0m));
    Assert.That(result.DiscountApplied, Is.LessThanOrEqualTo(500m));
}

Configuration: it reads your existing files

The debugger automatically creates launch configurations for runnable projects in your solution. If you already have a Properties/launchSettings.json — the same file Visual Studio and dotnet run use — ReSharper picks it up without additional configuration. Environment variables, application URLs, and command-line arguments all carry over.

If you are migrating from C# Dev Kit or NetCoreDbg, your existing launch.json configurations are directly reusable. ReSharper also provides code completion snippets when you create new configurations manually, with templates for process attachment, executable launches, and web applications.

For most projects, you will not need a launch.json at all — ReSharper auto-generates debug configurations from your solution's runnable projects. When you do need manual configuration, the extension provides code completion snippets with predefined templates for launching executables, attaching to processes, and debugging web applications. Type a { inside an empty launch.json configurations array and ReSharper will offer the available templates.

// NOTE

The debugger supports .NET, .NET Framework, and Mono targets. However, legacy .NET Framework launch scenarios (WPF applications, for example) may fail on initial launch. The workaround is to start the application outside the debugger and then attach to the running process.

Value Tracking: the feature you did not know you needed

Debugging is the headline, but Value Tracking might be the feature that saves you the most time day-to-day. It visualises how data flows through your code at design time — no debugger session required.

Right-click on any variable or expression and choose Show Value Origin to trace where a value comes from, or Show Value Destination to see where it flows to. The extension builds a navigable tree showing the chain of assignments, method calls, and transformations that connect a value to its source or its consumers.

This is particularly useful for two scenarios that eat hours during debugging:

Tracking down NullReferenceException sources. Instead of setting breakpoints and stepping through execution to find where a null value was introduced, Value Tracking shows you the entire chain of assignments from origin to the point of failure. You can often identify the problematic code path without running the application at all.

Understanding unfamiliar codebases. When you land in a large solution and need to understand how a particular value reaches a specific method, Value Tracking gives you the answer faster than grep ever could. It understands method boundaries, property assignments, and constructor injection — the kind of cross-cutting data flow that text search cannot reconstruct.

Hierarchy views done properly

ReSharper 2026.2 also ships Call Hierarchy and Type Hierarchy views populated by the ReSharper analysis engine. These are not new concepts, but the implementation quality matters.

Call Hierarchy lets you trace how a method invocation ripples through the codebase. Toggle between incoming calls (who calls this method?) and outgoing calls (what does this method call?) to build a complete picture of a method's context. Single-click navigation takes you directly to each call site.

Type Hierarchy shows inheritance relationships — supertypes and subtypes — for any class or interface. When you are working with a deep inheritance tree or trying to understand which implementations exist for an interface, this view gives you the answer without hunting through the Solution Explorer.

Solution Explorer improvements

Three smaller but practical additions round out the release:

NuGet package versions are now displayed inline in the Solution Explorer tree. When you are auditing dependencies or hunting for version conflicts, the version number is right there next to the package name. No more opening a .csproj file or running dotnet list package to check what version you are actually using.

Service folders get automatic priority. Folders like Properties and wwwroot are pinned above standard folders in the tree, matching the visual hierarchy you are used to from Visual Studio and Rider.

Add Existing Project appears in the context menu, letting you pull external projects into your solution without editing the .sln file by hand.

The C# Dev Kit question

The elephant in the room is why this matters beyond "JetBrains shipped a debugger." The answer is Microsoft's licensing decisions.

C# Dev Kit — Microsoft's own extension for .NET development in VS Code — is proprietary software that is restricted to genuine Visual Studio Code installations. Microsoft enforces this through licensing terms that explicitly exclude Cursor, Kiro, Google Antigravity, Devin Desktop, and any other VS Code-compatible editor. The latest releases of C# Dev Kit will not even install on these editors.

This means that if you use Cursor for its AI capabilities, or Kiro for its specification-driven development workflow, or any other VS Code fork for whatever reason, you had zero official options for .NET debugging until now. The open-source C# extension provides syntax highlighting and basic IntelliSense, but its debugging support is minimal compared to what C# Dev Kit offers.

ReSharper 2026.2 changes that equation. With this release, developers on non-Microsoft editors get code analysis, refactoring, navigation, unit testing, value tracking, and debugging — a more complete package than C# Dev Kit provides even on VS Code proper.

// IMPORTANT

VS Code allows only one extension to register as the debug engine for a given language. If C# Dev Kit is installed alongside ReSharper, the ReSharper debugger cannot take over debugging sessions. To use ReSharper's debugger, disable or uninstall C# Dev Kit and any other C# debugging extension, then reload the editor.

Licensing

The licensing model has not changed from 2026.1. ReSharper for VS Code is free for non-commercial use, which covers:

Commercial use requires a ReSharper, dotUltimate, or All Products Pack subscription. The first year of a commercial ReSharper licence runs $139 for individuals or $349 for organisations, with discounts in subsequent years.

If your team already has ReSharper or dotUltimate licences for Visual Studio, those same licences cover the VS Code extension — no additional purchase required.

Common pitfalls

Leaving C# Dev Kit installed. The single-debug-engine restriction in VS Code means you cannot run both. If you install ReSharper and wonder why F5 still launches the C# Dev Kit debugger, check your extensions list. Disable C# Dev Kit's debugging component or uninstall it entirely, then reload.

Expecting WPF launch-and-debug on .NET Framework. The initial debugger release has a known limitation with legacy .NET Framework launch scenarios. WPF and WinForms applications on .NET Framework may not launch correctly under the debugger. The workaround is straightforward: start the application normally, then use the "Attach to Process" configuration to connect the debugger. This limitation does not affect .NET 8+ or .NET 10 applications.

Confusing Value Tracking with runtime debugging. Value Tracking is a static analysis feature — it traces data flow through your code's structure, not through a running execution. It will not show you runtime-specific paths like values computed from database queries or API responses. For those, you still need breakpoints and the debugger. The two features complement each other: use Value Tracking to narrow down where to look, then use the debugger to confirm what actually happens at runtime.

Assuming this replaces Rider. ReSharper for VS Code is now a genuinely capable .NET development environment, but Rider still offers database tools, Docker integration, profiling (dotTrace and dotMemory), game engine support (Unity, Unreal, Godot), and deeper AI agent integration through the ACP Registry. If you need those capabilities, Rider remains the more complete option. ReSharper for VS Code is for developers who prefer VS Code's editing model and extension ecosystem but want deeper .NET tooling than C# Dev Kit provides.

Summary

ReSharper 2026.2 for VS Code delivers on the promise that was explicitly missing from the March launch:

The extension is available now from the Visual Studio Code Marketplace and the Open VSX Registry. If you tried ReSharper for VS Code at launch and bounced off the missing debugger, this is the release that closes the gap.