Debugging Sitecore OOTB Personalization Rules

This topic could apply to any .NET application in regards to a closed source third party assembly, but I thought it would be helpful to give it some context and speak to the Sitecore community. It also isn't the first time any post has surfaced on the technique, but its always more helpful to have perspective from multiple authors.

What we're trying to do is use one of the out-of-the-box rules to personalize a component. If a visitor signs up and tells us in their profile that they are in a certain industry, then we will show an image on the carousel that yields a coupon. While there is no programming to set this up, more complex situations may not go as planned, and it will come back to the developer for troubleshooting.

Here is the OOTB User Profile rule. You can see the location of the rule, the class, and assembly name.

Here is the usage of the rule. We can debug the input parameter to see if comparisons are working when the personalization engine fires.

To step into the Sitecore.Kernel, I used the x64 bit standalone version of DotPeek: https://www.jetbrains.com/decompiler.

Then I make a note of the default port of the symbol server, change the settings to only serve up symbols for assemblies in the explorer, open Sitecore.Kernel from the Sitecore bin directory, and remove all other files from the explorer.

Next, right-click the Kernel and Generate PDB. Make a note of the location.

During debugging you may get a message in the debugger preventing you from seeing local variables because of assembly optimization. There are two steps to prevent this; the first is to set up this .cmd file and then run it as administrator.

The second is to create a file called Sitecore.Kernel.ini in the bin directory with these values. If there are other assemblies you're interested in, then you'll have to create a file for those too.

In Tools > Options > Debugging in Visual Studio set: General > Check 'Enable .NET Framework Source Stepping' and Uncheck 'Enable Just my Code'. Then point to the symbol server for dotpeek.

Start the symbol server if it isn't started already, attach to w3wp process, and create a breakpoint on the desired function. The function and namespace can be found from dotpeek.

The attach process could take quite some time, so hopefully this is not an everyday task. I have also read that Reflector has better performance, but there may be a licensing cost. Here is a screenshot proving that we stepped into the breakpoint.

Why did we have to do this?

It turns out our custom profile property is backed by a droplink, which behind the scenes is a GUID of that selection value and not a text. We actually had comparison issues using the text value, even though pasting the GUID in the rule editor resolved back to the actual text value of our industry. There may be other ways to solve this, but the important part is that we were able to quickly draw conclusions by seeing it in action.