Quite often, debugging Sitecore assemblies becomes very essential for developers, to investigate any exception or unintended behavior happening within Sitecore assemblies (or any Third-party managed code). While there are few options available currently to debug Sitecore assemblies with tools like dotPeek, dnSpy, etc., it would incur some effort to install and configure them to be able to debug.
Visual Studio by partnering with ILSpy has now made it easy by bundling this capability in Visual Studio 2019. This works great for both Docker-based and non-Docker-based implementations.
Visual Studio 2019 version 16.10.0 is required to use this feature, you may upgrade to 16.10.0 using the regular Visual Studio Installer.
Though this feature was introduced in Visual Studio 2019 version 16.5, decompiling Sitecore assemblies were experiencing the below ‘Unable to decompile the module.’ issue which was addressed in 16.10.0,
STEPS TO DEBUG SITECORE DLLS:
- Navigate to Debug -> Options and uncheck the ‘Enable Just My Code’ option
- Start debugging the application
- Once the debugger hits a breakpoint, launch the Modules window by navigating to Debug -> Window -> Modules (or Ctrl+Alt+U)
- Identify the module/dll(Eg: Sitecore.Xdb.MarketingAutomation.Tracking.dll) that needs to be debugged (You can also right-click on the intended function and navigate to its definition(metadata) to identify the related Sitecore dll)
- Right-click on the identified module/dll and select ‘Decompile Source to Symbol File’ option. It may take up to 1-3 mins for decompilation depending on the size of the assembly.
- Once the Symbol File generation is complete, add a Function Breakpoint by navigating to Debug -> New Breakpoint -> Function Breakpoint (or Ctrl K, B) and specify the Sitecore method name along with it’s namespace(Eg: Sitecore.Xdb.MarketingAutomation.Tracking.Extensions.ContactExtensions.GetPlanEnrollmentCache)
- Press Continue or F5, you will now be able to step through the Sitecore or Third-Party code!
Decompiling Sitecore assemblies using this feature is currently possible only when the debugger is in break mode and the application is paused. Visual Studio enters break mode when it hits a breakpoint or an exception. Alternatively, Visual Studio can be forced to enter break mode by selecting Debug -> Break All after attaching the specific IIS process. There are a few known limitations, which are covered here.
For remote debugging, you will still be needing the Remote Debugger application in Target Environment.