Edit & Continue, Just-in-time Debugging, and more debugger improvements in Rider 2019.1

Probably the most fundamental technique in software development is Changing Stuff and Seeing What Happens. Rider 2019.1 EAP brings new features and several fixes for its powerful debugger, including edit-and-continue functionality and just-in-time debugging.

Edit & Continue

One of the highest voted feature requests for the debugger is finally here! Edit & Continue is now supported for projects targeting .NET Framework and .NET Core on Windows (except WPF). That means we can keep our application running, change the code, and continue debugging without actually restarting. The project will just recompile in the background:

Edit & Continue on Windows

There are cases when modifying the code is not possible and a restart is required. This includes changing signatures, working in generic functions, renamings of any kind, and some more. Rider will make us aware by showing a tooltip:

Modifying generic methods prevents from continuing

Note that Edit & Continue is currently only supported on Windows as the other runtimes do not implement the required debugger APIs.

Just-In-Time Debugger

Calling Debugger.Launch is an effective way to dynamically attach the debugger whenever a certain place in our codebase is executed. In contrast to starting with the debugger attached or attaching it manually, this method can save us a lot of unnecessary execution time. If the debugger is attached, our application will run slightly slower, as the debugger has to follow what’s happening.

With the release of 2019.1 EAP we get the opportunity to configure Rider as our just-in-time debugger under Build, Execution, Deployment | Debugger:

Setting the default debugger

Whenever a process calls for the just-in-time debugger, we get a dialog to choose from a list of currently opened solutions, and installations that can be launched (1). An additional checkbox allows to remember the selected option (2), in which case for every future attempt, the debugger will automatically be attached:

Selecting Just-in-time debugger

Tooltip Evaluation

Hovering an expression with the mouse lets us quickly take a glimpse at its actual result, regardless of its type. This feature now works with any expression type:

Evaluating an expression by selection

Did you know that you can inspect expressions also in a more keyboard-centric way? For this to work, first enable the Show value tooltip on code selection option under Build, Execution, Deployment | Debugger | Data Views:

Enabling evaluation from code selection

Afterwards, we can use the caret and the extend/shrink selection (Shift+Control+W or Shift+Command+W) action, to select expressions of our choice. A tooltip will appear right away:

Evaluating an expression by hovering

Another way of evaluating an expression is to use the Quick Evaluate Expression action (Alt+Click or Option+Click) that turns any arbitrary expression into a clickable link which then reveals the value as a tooltip:

Evaluating an expression by clicking

Enhancing debugger experience

The DebuggerDisplay attribute is a good way to enhance our debugging experience. It allows to define how a certain type is represented in the debugger, without overriding ToString, which could change the actual runtime behaviour.

Rider 2019.1 EAP improves the support for DebuggerDisplayAttribute, which now correctly shows nullable types as null instead of the previous behaviour (RIDER-10280, RIDER-24334):

Representation from DebuggerDisplayAttribute

We’re looking forward to your feedback about our recent debugger improvements. Download Rider 2019.1 EAP now, and give it a try!

This entry was posted in How-To's and tagged , , , , . Bookmark the permalink.

10 Responses to Edit & Continue, Just-in-time Debugging, and more debugger improvements in Rider 2019.1

  1. ju says:

    Am I wrong or it is currently impossible to debug more than one app behind IIS express ?
    For instance if I have an app calling another, it would be nice if I could “traverse” them while debugging (hit break points set in both) behind IIS express. Should I log an issue for this ?

    • Ivan Migalev says:

      Hello! Could you please clarify your request a bit? For now, you should be able to easily start multiple IIS Express applications (either with the “Debug” button, with the compound run configuration, or by attaching to multiple IIS Express worker processes), and then debug them all simultaneously in multiple debug sessions.

      Is it the same you’re suggesting, or do you want some additional debug functionality?

  2. cocowalla says:

    I’ve been using Edit & Continue in the 2019.1 EAP, and it’s fantastic!

    It’s a feature that I’ve always found flakey in Visual Studio, when it worked at all, so this is a real killer feature in Rider for me!

  3. Jonathan Coplon says:

    Any word on docker-compose debug support?

  4. Kai Michael Wadsack says:

    What about Edit and Continue on Mac?
    And what about profiling on Mac?
    Currently it doesn’t seem to be supported in .NET Core.

  5. Oleksii Vynnychenko says:

    Question about “Edit & Continue”: how to ignore changes (don’t apply changes) and continue debugging?
    Previously changes didn’t apply obviously so I could modify code and continue debug. Yes, Rider could potentially display wrongly line where debugger stopped or show weird line selection but it worked completely OK. Now when I add attribute for example -> Rider says obviously that I need to recompile and I can’t continue debugging.
    And it’s a regression – I could modify code in some unrelated class that I have no intent to debug and it doesn’t conflict with anything.

    What I’m trying to say that it would be good if Rider would warn that I need to recompile (it already does) but don’t try to apply changes if I won’t be able to continue debugging.
    Or am I missing something?

  6. Kevin Boss says:

    Is there a roadmap for Edit & Continue for WPF Applications?

Leave a Reply

Your email address will not be published. Required fields are marked *