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
Thanks, we've got you!
Eager, Lazy and Explicit Loading with Entity Framework Core
Entity Framework Core (EF Core) supports a number of ways to load related data. There’s eager loading, lazy loading, and explicit loading. Each of these approaches have their own advantages and drawbacks. In this post, let’s have a quick look at each of these ways to load data for navigational prope…
OSS Power-Ups: bUnit – Webinar Recording
The recording of our webinar, OSS Power-Ups: bUnit, with Egil Hansen and Steven Giesel, is available. This was the twelfth episode of our OSS Power-Ups series, where we put a spotlight on open-source .NET projects. Subscribe to our community newsletter to receive notifications about future webi…
Accelerating Your Testing Workflow with Unit Test Creation and Navigation
Unit tests play an important role in our daily development workflow. They help us ensure our codebase's correctness when writing new functionality or performing refactorings to improve readability and maintainability. In the process, we often create new test files that accompany the p…
Introducing Predictive Debugging: A Game-Changing Look into the Future
With the introduction of debugging tools, software developers were empowered to interactively investigate the control flow of software programs to find bugs in live environments. At JetBrains, we've always strived to improve the art of debugging. Besides the more standard things you expect from a de…