DotRush gives VS Code a C# debugger, profiler and test runner

An IDE subset that leans on the .NET SDK

DotRush is described as a lightweight C# development environment for Visual Studio Code, and the way it delivers that weight is the interesting part. The extension itself is thin. The intelligence comes from Roslyn based autocompletion, suggestions and code navigation, the debugger and profiler are driven by the dotnet command line tools, and the decompiler is ICSharpCode Decompiler, the library behind ILSpy.

The repository is a TypeScript VS Code extension. The package.json declares a single runtime dependency, vscode-languageclient at ^9.0.1, which is the client half of the language server protocol. Everything else in the dependency list is a build time concern: webpack and ts-loader bundle the extension, and speedscope and memoryviewer are the two web viewers the profiling and heap dump features embed.

The package declares a single runtime dependency, vscode-languageclient at ^9.0.1, which is the client half of the language server protocol. The extension requires VS Code ^1.83.0, and its activation events are onLanguage:csharp, onDebug and workspaceContains for project, solution, C# and XAML files, so it wakes only when there is C# to work on.

The licence is MIT, and the extension is published on the Open VSX registry under the nromanov publisher with the display name DotRush, authored by Nikita Romanov.

The MIT licence covers the extension code. The licence of the SDK tools it drives, of Roslyn, and of ICSharpCode Decompiler are separate matters, and any specific compliance question belongs with your own counsel.

The debugger is configured through launch.json

Running and debugging a .NET Core application starts with F5 and the .NET Core Debugger configuration, and the documentation shows the equivalent launch.json, which is the part worth copying:

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": ".NET Core Debugger (launch)",
            "type": "coreclr",
            "request": "launch",
            "program": "${command:dotrush.activeTargetPath}",
            "preLaunchTask": "dotrush: Build"
        },
        {
            "name": ".NET Core Debugger (attach)",
            "type": "coreclr",
            "request": "attach",
            "processId": "${command:dotrush.pickProcess}"
        }
    ]
}

Two custom commands appear in there. The program field is a command reference, ${command:dotrush.activeTargetPath}, rather than a hard coded path, and the attach configuration uses ${command:dotrush.pickProcess} so the process is chosen interactively.

The startup project is set separately, by clicking it and running Set as Startup Project from the context menu, and the debugger options live in the VS Code settings. In a folder with several projects or a solution file, DotRush shows a picker, and it saves the selected projects and solutions in the workspace settings so the choice survives a reload. The picker can also be opened on demand with the DotRush: Pick Project or Solution files command.

Profiling is dotnet-counters, dotnet-trace and dotnet-gcdump in a UI

The profiler section is the part that makes this more than a debugger wrapper, and the mechanism is that DotRush runs the SDK tools and renders their output.

Three tools are covered. The realtime Performance View starts automatically with the .NET Core Debugger and uses dotnet-counters to show two live charts of the debugged process, CPU usage alongside time in GC, and working set alongside GC heap size.

The Trace Profiler is attached on demand with the DotRush: Attach Trace Profiler command, which runs dotnet-trace in the terminal. You press Enter in the terminal to stop collection, and the generated .nettrace.json file is opened in the speedscope viewer, which is bundled as a dependency rather than linked out. The profile selector switches between three views, CPU across all threads showing where managed code spends CPU time, Allocations weighted in bytes showing the allocated types with their allocating call stacks as a sampled estimate of about one sample per 100 KB, and Thread profiles showing the wall clock timeline of every thread including blocked time.

The Memory Dump runs dotnet-gcdump and snapshots all live objects, producing a .gcdump.json file that opens in the bundled memory viewer. That viewer has six views: Summary with heap types, instance counts, shallow size and retained size, Dominators showing the tree of what keeps each object alive, GC Roots, Graph, Leak Suspects for detected patterns such as objects kept alive only by delegates or event handlers with many subscribers, and Compare, which diffs the types against a second snapshot of the same process.

Unity debugging gets its own configuration type

Unity projects are handled by the integrated Mono Debugger, and the launch.json for it uses a unity debug type rather than coreclr:

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Unity Debugger",
            "type": "unity",
            // Attach to Android device
            // "transportArgs": {
            //     "type": "android"
            // },
            "request": "attach"
        }
    ]
}

The configuration is attach only, which matches how a Unity project is debugged in practice, and the commented block shows how to point the transport at an Android device by setting the transportArgs type to android.

The README also has a section on debugging Godot projects that opens with the instruction to open the project in VS Code and create a launch.json, and the text is cut off there in the version available here, so the Godot configuration details are not documented in what can be read.

The Test Explorer, by contrast, is fully described. For VSTest tests, that is NUnit, xUnit and MSTest, you run a test with the run button next to it, or right click that button and pick Debug Test to debug it. It is integrated into VS Code rather than being a separate window.

Diagnostics across every target framework

The feature list calls the last capability multitarget diagnostics, described as real-time linting and error detection to catch issues early in all target frameworks of your project.

The word multitarget is the load bearing one. A .NET project that multi-targets, for example net8.0 and net472 at once, has a different set of available APIs and a different set of possible errors in each target. A diagnostic that only understands the current target framework will report problems that do not exist in another one, or miss problems that do.

The IntelliSense side is Roslyn based, which means the completion and suggestion behaviour comes from the same compiler that builds the project, and the code navigation is driven by the same analysis rather than by a separate indexer.

For the decompilation feature, the README points at ICSharpCode Decompiler, the library behind ILSpy, and the promise is to view the underlying source of a compiled assembly instantly. That is a debugging aid for when you need to see what a referenced library actually does, and it is the feature that most obviously borrows from Visual Studio rather than from the .NET SDK.

Themes, packaging and how the release cadence works

The extension also contributes themes, which is a smaller feature but a common source of friction when moving from Visual Studio. The package contributes Visual Studio 2022 Dark, Visual Studio 2022 Light and Visual Studio Classic, each pointing at a JSON file in the themes directory, with the uiTheme values vs-dark and vs. The repository has a themes directory and a webpack.config.js, and the packaging script is a production webpack build.

The build itself is a small TypeScript setup. The watch script is tsc -watch against src/VSCode/tsconfig.json, and package is webpack --mode production, run through vscode:prepublish. There is a build.cake file for Cake based tasks and a .vscodeignore and .config directory for the extension packaging conventions.

The release names are dated, with 2026.10 tagged on 2026-10-04, 2026.09 on 2026-09-13 and 2026.08 on 2026-08-02, so the version is a month rather than a semantic version, and the package.json inside the repository reads 1.0.0, which is the Open VSX extension version and is not the same numbering.

The repository is not archived and the last push was on 2026-10-18, and the CodeQL workflow badge in the README shows that the project runs GitHub's code scanning on itself, which is a reasonable thing to see on an extension that executes debugger and profiler tooling.

Editorial conclusion

DotRush suits a C# developer who wants debugging, profiling and test running inside VS Code without installing Visual Studio, since the profiler and debugger views are driven by the dotnet-counters, dotnet-trace and dotnet-gcdump tools that ship with the SDK. It is the wrong choice for a project that needs the full Visual Studio feature set, and the decompiler is a debugging aid rather than a substitute for a real decompilation workflow. Before adopting it, install the .NET SDK and confirm the dotnet-counters, dotnet-trace and dotnet-gcdump tools resolve on your PATH, then check the launch.json configuration for the coreclr and unity debug types, since those are what drive F5.

Frequently asked questions

Official sources

1. JaneySprings/DotRush on GitHub
2. License: MIT
3. Project website
4. README
5. Releases