How to Debug Orchard Core NuGet Packages

[fuzl-llc]

I've had many times where something was going wrong and I wanted to know exactly what Orchard was doing. For simple issues, I could just download all the OrchardCore source and build/run/debug like any other .NET solution for which I have the source code. However, sometimes I have an issue where there is a mix of my custom code that builds on top of Orchard and I want to debug my code and Orchard's code without having to copy my code into the Orchard project or other inefficient ways I've tried to solve this issue (generally ending in weird code version mismatches and other mayhem that was extremely frustrating and time consuming). Further complicating things are cases where I wanted to debug the execution of startup code of Orchard Core modules built in release mode that I was referencing from the official NuGet packages.

This may be obvious/easy information for some people but I tried and failed a number of times to find an easy and efficient way to debug Orchard Core code in various situations. So, I wanted to document here in case it might help someone else and for me to be able to look back at when I inevitably forget in the future. I'm using the OrchardCore.Liquid module for this example as I recently had a case where I was referencing its NuGet package and wanting to debug its startup behavior.

1. Go to "Tools > Options > Debugging" and uncheck "Enable Just My Code."
2. Go to "Tools > Options > Debugging > Symbols" and check "NuGet.org Symbol Server."
3. Press F5 to debug a solution that has custom modules referencing Orchard Core nuget pacakges such as OrchardCore.Liquid.
4. You should see an "External Sources" node just under the root solution node in VS solution explorer (only when actually debugging).
5. Expand "Modules without sources," right click "OrchardCore.Liquid" and select "Always Load Automatically."
6. "OrchardCore.Liquid.dll" should now show up directly under "External Sources" (not in "Modules without sources").
7. Expand the "OrchardCore.Liquid.dll" node and you'll see the exact source code used to build that version of the DLL.
8. Place breakpoints wherever you want and when you debug in the future, even in startup code, those breakpoints should be hit.

Note: in step #5 above, I had originally selected "Load Symbols" but my breakpoints ended up with the dreaded yellow triangles that said the breakpoint won't be hit... so it is important to select "Always Load Automatically" if you want to hit breakpoints in startup code.

Thanks to the Orchard Team for doing the right things, as usual, to ensure the openness and availability of everything we could possibly need... in this case making sure proper symbol libraries and code are available... because it is pretty easy to debug once you know what to do.

[Piedone]

Thanks for sharing! Indeed, once you set this up, you can just debug into OC as if it were code.

Would you like to copy this into the docs? https://docs.orchardcore.net/en/latest/contributing/contributing-documentation/

[fuzl-llc]

Yes, I was wondering if I should have asked to put this in the docs instead... I'll try to find some time to re-learn how to contribute to the docs and add it there. Thanks!

[Piedone]

Thank you!

[DavidStania]

@fuzl-llc thank you for sharing this solution! It helps me a lot today.