More meaningful call stacks, thread-specific breakpoints and other debugger improvements in Rider 2018.2 EAP
Our latest Rider 2018.2 EAP (Early Access Preview) introduces a series of improvements to the debugger. Generic types, async function names, constructors, static methods and other type information in .NET call stacks are now displayed in a more meaningful way. We added thread-specific breakpoints for multi-threaded applications. Mono and Unity developers will be happy with the ability to inspect unsafe pointers. It’s now possible to change debugger settings while running. And more! Let’s have a look.
Improved type information in .NET call stack
While debugging, we can inspect what our code is doing. When execution is paused, we can inspect variables, and see the current execution stack. Traditionally, this stack displayed type information as seen by the .NET runtime. For example, when debugging
async methods, we would see the underlying state machine in our call stack, rather than the name of our
No longer! Rider 2018.2 comes with improvements in presenting generic types, async function names, constructors, static methods and other type information in .NET call stacks. Instead of that
MoveNext() method, we can now see the name of our
Rider now displays call stacks that make use of modern C# features in an understandable way.
Presentation improvements were made for various language constructs: in the following example, we can see generic parameters are displayed in method signatures and class names. Constructors are no longer displayed as
.ctor, instead they are shown as the type name with new in front of them. Static constructors are shown as static.
The memory view now also formats types using this approach, showing C# types instead of CLR types.
These improvements should make debugging and exploring call stacks in the debugger much more productive!
Debugging multi-threaded applications can be challenging: whenever we continue execution, we may be on another thread the next time our breakpoint is hit. In Rider 2018.2, we’ve added thread-specific breakpoints to make debugging of multi-threaded code an easier task.
In the following example, chances are that when stepping through code we will first see
i = 0 a number of times, as each of the threads executing this code initializes
0 within its own scope. However, we can edit our breakpoint (using the context menu) and suspend only on a specific thread. Our breakpoint will then only be hit when it is reached in the particular thread we are interested in.
By default, Suspend only on specific thread selects the currently active thread. We can also switch to a particular thread, which can be useful when working with named threads, for example.
Support inspecting and expanding unsafe pointers
Unsafe pointers could not be expanded while debugging under Mono versions before 5.0. Thanks to a contribution to the Mono project by the folks at Unity, we were able to make an update to the Rider debugger where pointers are followed and expanded.
In the following example, the
EntityManager.Entities property (which is a pointer to an
EntityDataManager) can be inspected from the debugger tool window:
Other debugger improvements
A number of other updates were made to our debugger. For example, it is now possible to change the debugger’s settings while it is running. This makes it possible to do things like enabling/disabling the Ask for location of missing source files setting to determine where sources are loaded from.
Smart Step Into now correctly handles methods that are decorated with the
[DebuggerStepThrough] attribute. Instead of suggesting to step into such method, Rider will step over instead.
For .NET and .NET Core, we now also support the
Debugger.NotifyOfCrossThreadDependency method. “What’s that?“, you may ask. This method can be used to signal the debugger that a thread has to run in order to display a watched property or method, and that the state of the application will change because of that. For those cases, Rider will not automatically refresh watches.
We also added an option to automatically refresh all watches in the debugger tool window on every debugger pause. The Automatically refresh watches on debugger pause checkbox can be found in the settings under Build, Execution, Deployment | Debugger | .
Download Rider 2018.2 EAP now! We’d love to hear your feedback on these improvements!
Subscribe to Blog updates
Creating Custom AI Prompts
AI has swept through the software development industry like a wildfire. So people want to learn how to best use AI in their day to day tasks. In this post we’ll take a look at how to write custom prompts for use with the JetBrains AI Assistant in ReSharper and Rider so you can make the most of AI.&n…
12 Debugging Techniques In JetBrains Rider You Should Know About
Twelve must know debugging features in JetBrains Rider every developer should know.
Interceptors – Using C# 12 in Rider and ReSharper
Welcome to our series, where we take a closer look at the C# 12 language features and how ReSharper and Rider make it easy for you to adopt them in your codebase. If you haven’t yet, download the latest .NET 8 SDK and update your project files! In this series, we are looking at: Primary …