Debugging Unity Play Mode in Rider: Attach, Breakpoints, and Burst Jobs

Why switching between Rider and Unity hurts iteration speed

When you edit a script in Rider and then jump back to the Unity Editor to test a change, you lose the immediate feedback loop that a tight edit‑run‑debug cycle provides. Each context switch forces Unity to recompile assemblies, reload the scene, and re‑initialize the Play Mode state, which can add several seconds—or more—to every test. For gameplay programmers iterating on mechanics, that overhead quickly becomes a bottleneck.

Thesis: Rider’s Unity plugin lets you debug Play Mode without leaving the IDE

By enabling the Unity plugin and using Rider’s built‑in attach‑to‑debugger feature, you can set breakpoints, inspect variables, and evaluate expressions while the Unity Editor runs, all from inside Rider. The same workflow works for edit‑mode tests and for Burst‑compiled jobs, giving you a single environment for coding, debugging, and testing.

Setting up the Unity plugin

1. Open Rider and go to Settings → Plugins.
2. Search for "Unity" and enable the JetBrains Unity plugin.
3. Restart Rider when prompted.
4. Open your Unity project (File → Open) – Rider should automatically detect the project and show the Unity logo in the status bar.

After the restart, verify that Unity‑specific inspections appear (e.g., a warning when a MonoBehaviour method signature does not match Unity’s expected message).

Worked example: debugging a MonoBehaviour Update method

Suppose you have a simple script that moves a GameObject each frame:

using UnityEngine;

public class Mover : MonoBehaviour
{
    public float speed = 5f;

    void Update()
    {
        transform.position += Vector3.forward * speed * Time.deltaTime;
    }
}

To debug this method while the game is running:

1. Place a breakpoint on the line inside Update() (click the gutter).
2. In Rider’s main toolbar, select Run → Attach to Unity Editor (or use the debug icon with the Unity logo).
3. Rider will attach its debugger to the running Unity Editor process. The status bar changes to indicate a debug session.
4. Return to the Unity Editor and press Play. When the script’s Update method executes, execution will pause at the breakpoint.
5. While paused, inspect the speed field and the transform.position value in the Rider Variables pane, or evaluate expressions in the Evaluate dialog.
6. Press F9 (or click Resume) to continue execution.

If the breakpoint is not hit, check that the Unity Editor is indeed the process Rider attached to (look at the attached process ID in the debug window) and that the script is part of the active assembly (no compile errors).

Debugging Burst‑compiled jobs

Rider’s Unity support also understands the Burst compiler. When a job is compiled with Burst, the debugger can still step into the generated native code if you enable the Allow unsafe code option in the Burst settings and launch the Editor with the -burstdebug flag (added via Rider’s Run → Edit Configurations for the Unity launch). This lets you inspect job data and verify that the Burst optimizations behave as expected.

Trade‑offs and limitations

While the integrated debugging workflow reduces context switching, it introduces some overhead:

• Performance impact: Each script assembly reload triggered by Unity causes Rider to resynchronize its debugging symbols. In large projects with dozens of scripts, you may notice a slight slowdown when stepping through code.
• Windows‑only tools: Certain profiling aids that ship with Visual Studio’s Unity Analyzer (e.g., deep GPU frame capture) are not available in Rider. Developers needing those features must still rely on external tools or the Unity Profiler.
• Version compatibility: Rider versions prior to 2021.2 lack the Unity plugin; older Unity releases (before 2019.3) may not expose the necessary API for full inspection.

To verify that the debugging overhead is acceptable for your project, you can:

1. Open Rider’s Help → Diagnostic Tools → Debugger Windows → Threads while a debug session is active.
2. Observe the thread count and CPU usage; if the debugger thread consistently consumes >20 % of a core during idle Play Mode, consider setting breakpoints only on the scripts you are actively investigating.
3. Alternatively, disable the Unity plugin temporarily (Settings → Plugins) and measure the time between a code change and the next Play Mode start; compare the two timings to gauge the plugin’s impact.

Actionable closing

If you spend more time switching between Rider and Unity than you do writing code, try the following steps today:

1. Enable the JetBrains Unity plugin and restart Rider.
2. Open a Unity project and confirm the Unity logo appears in the status bar.
3. Set a breakpoint in a frequently edited MonoBehaviour method.
4. Use Run → Attach to Unity Editor and press Play in the Unity Editor.
5. When the breakpoint hits, inspect variables and evaluate expressions without leaving Rider.
6. Monitor debugger overhead via the Threads window; adjust breakpoint density if needed.

By keeping your edit‑run‑debug loop inside a single IDE, you reduce idle time and keep your focus on the gameplay logic you are building.