Debugging third-party code with Rider
If you are using any third-party library, either via NuGet or other sources, you probably have experienced the case where something does not work as expected. To figure out what’s going on we sometimes need to debug into that third-party library (or even just the .NET Framework itself). Making that work is usually another painful process in itself, setting up symbol servers and finding matching PDB files etc. Usually by the time you get this all working, you forgot what you wanted to debug in the first place.
The latest Rider 2017.3 EAP build solves all of the above, and makes stepping into third-party code a breeze! Here’s a simple ASP.NET application where we will use Step Into (F11) to debug the ASP.NET Core source code.
We’ve just stepped into ASP.NET Core’s
StaticFileExtensions, and even into .NET Core’s
Array class – debugging third-party code without any effort!
Rider accomplishes this feat by using the dotPeek decompiler, decompiling third-party code on the fly and injecting it into the debugger. Note that support for downloading existing PDB’s and things like SourceLink is not there yet.
The first time we step into third-party code, Rider will show a notification mentioning decompilation occurs, and we can optionally disable it there. Debugging of third-party code can be enabled/disabled from Rider’s settings under Build, Execution, Deployment | Debugger, then Enable external source debug. If at any point you’d like to clear the decompilation cache, you can remove the data in
Debugging third-party code is possible in full .NET Framework and .NET Core. Mono support is being worked on. This means we can pull of the same trick on Linux or Mac OS X with .NET Core!
Setting breakpoints in third-party code
In Rider, we can Ctrl+click into a class or method (or use Navigate To – Alt+` or any of our other navigation features). This works for our own code, but also for third-party code thanks to the integrated decompiler. Rider now supports setting breakpoints in decompiled code, and during a debugging session will suspend execution if a breakpoint is hit!
Let’s navigate into one of ASP.NET Core’s methods, add a breakpoint there, and then start the debugger:
Navigating the stack trace with third-party code
During a debug session, we can always see the stack trace in the Debugger tool window. When double-clicking any stack frame, Rider will either navigate to the code directly (if it’s in our own codebase), or decompile the code for that stack frame and open it in the editor.
Attach to a running process
Another nice example of where this feature comes handy is attaching to a running process. From any open project (or from an empty solution or open folder), we can use the Run | Attach to Local Process… (Ctrl+Alt+P) and attach to any running .NET or .NET Core process.
Once attached, we can pause execution at any point in time and start exploring the running application in the debugger. Even if we don’t have the sources available!
We can also place breakpoints in external code. For example using Go to Everything (Ctrl+T), we can navigate into third-party code and add a breakpoint there. While debugging, Rider will pause execution when we hit the breakpoint:
PS: If you wish to debug third-party code in Visual Studio, you can follow the steps in this guide on setting up dotPeek as a symbol server.
Give the latest Rider 2017.3 EAP build a try and let us know what you think of debugging third-party code!
Subscribe to Blog updates
Thanks, we've got you!
Visualize Entity Framework Relationships and Additional Query Analysis in ReSharper 2023.3
A lot of teams are using Entity Framework or EF Core to work with their database. As an Object-Relational Mapper (ORM), it bridges objects in code to a relational database model, so that as a developer you don’t have to worry too much about the actual database. We all know: that’s not entirely tr…
Automatically Analyze ASP.NET Core Performance With Dynamic Program Analysis
Slow web pages may make your users or customers abandon your web application, even before they’ve had a proper look at it. You’ve likely also been frustrated working with a web application that is slow to load. The good news is that the latest versions of ReSharper and JetBrains Rider’s Dynamic P…
OSS Power-Ups: MassTransit – Webinar Recording
The recording of our webinar, OSS Power-Ups: MassTransit, with Chris Patterson, is available. This was the thirteenth 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 webinars.…
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…