Debugging third-party code with Rider

Posted on by Maarten Balliauw

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.
Debugging third-party assemblies in Rider

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 %USERPROFILE%\.Rider2017.3\config\resharper-host\DecompilerCache.

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!
Debugging third-party code on Mac OS X with Rider

Setting breakpoints in third-party code

In Rider, we can Ctrl+click into a class or method (or use Navigate ToAlt+` 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:
Set breakpoint in external code

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.
Explore and decompile stack trace in Rider debugger

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:

https://youtu.be/hK7OMSej4iU

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!

Comments below can no longer be edited.

15 Responses to Debugging third-party code with Rider

  1. Joseph Woodward says:

    December 20, 2017

    Awesome work, and just before Christmas.

  2. Happy Man says:

    December 20, 2017

    Thank you.

  3. lou says:

    January 8, 2018

    awsome

  4. Andrew says:

    January 23, 2018

    Just awesome!

  5. Aidan says:

    January 27, 2018

    This functionality is incredibly useful. Thank you for your hard work and making the Jetbrains toolbox subscription more useful than ever. One quick question though – is there any approximate ETA on adding Sourcelink support? 2018 perhaps?

  6. Daniel says:

    May 8, 2018

    I cannot debug .net Framework code, I get the following
    Evaluation is not allowed: The thread is not at a GC-safe point

    • Artem Bukhonov says:

      May 8, 2018

      This usually happens when you stop your process using Pause action or when you debug an assembly which was built in Release mode. In this case stopped thread may be in a state which doesn’t allow function calls, because GC isn’t ready yet.
      You may get more details here https://blogs.msdn.microsoft.com/jmstall/2005/11/15/rules-of-funceval/

  7. Rupert says:

    October 22, 2018

    When running with Unity, Rider doesn’t / no longer (?) seems to step into and decompile the Unity DLLs. (I have this niggling feeling this used to work?)

    Is this due to the Mono restriction? What’s the ETA for that changing?

    Those DLLs are perfectly susceptible to decompilation with “go to source” (F12 Windows). Is there some ‘half way’ approach that might be possible? E.g. when whatever this restriction is is present, perhaps show us the location that F12 would have shown for one ‘step’ ?

    Thanks (and Rider is still super awesome 🙂 )

    • Matt Ellis says:

      October 22, 2018

      Hi Rupert. This should still be working with Mono and Unity. Could you make sure the “Enable external sources debug” option is checked in Preferences -> Build, Execution, Deployment -> Debugger, please? If this doesn’t work, can you create an issue at https://youtrack.jetbrains.com so we can follow up with more details, e.g. is it step into that’s not working, or double clicking on an entry in the debugger call stack toolwindow?

  8. alex says:

    October 26, 2018

    Is possible to link the actual dotnet source code to the decompiler if the source code can be found (ex: https://github.com/dotnet/corefx)

  9. Glenn says:

    July 30, 2019

    How can I debug 3rd party attributes ? Let’s take an example of DataAnnotations in asp.net MVC. With “debug external resource” checked in settings, I can easily debug 3rd party libraries but I am not at all able to debug Attributes ?
    I am trying to debugg some data annotation attributes.
    Is there a way to do this in Rider ?
    Thanks .

    • Maarten Balliauw says:

      July 30, 2019

      Depends on whether the code in the attribute gets called at some point or not. You could try to Ctrl+Click into the attribute, then place a breakpoint if that attribute has any logic that is being executed.

  10. Danielku15 says:

    August 12, 2019

    It would be awesome if you can filter for which third party code you want to have debugging active. It is really helpful for 3rd party libraries but the fact that Rider steps into each and every BCL method/property is a nightmare. If I want to step into my method I do not want to debug the cancellation token construction or a list constructor every time, I want to get into my method. e.g. a Step-into to a await _externalLibInstance.DoSomethingAsync(new List{ 1,2,3}, CancellationToken.None) should step into the DoSomethingAsync, not first the list constructor and the None cancellation token access.

    Is there maybe already a setting I missed?

Subscribe

Subscribe to .NET Tools updates