Debugging 101: The Pitfall of the plugin profiler

When developing for CRM, you sometimes have to debug your code. With the CRM on-premise versions, one could simply attach the Visual Studio debugger to your CRM Server.

You only had to install the Visual Studio Remote debugging tools, update the plugin, copy the corresponding plugin pdb file to the assembly bin folder on the server, attach the Visual Studio debugger to the CRM processes on the remote server (either the W3WP, sandbox or async processes) and you were good to go.

Back then, debugging was a breeze! Nowadays using CRM online, debugging is much harder.
Instead of connecting the Visual Studio debugger directly to the one of CRM processes on the remote server, we attach the debugger to the plugin registration tool in which we recorded a profile using the profiler. Before we can do that we have to install the profiler on the CRM organization to which we are connected, and after that attach the profiler to the plugin steps you want to debug.

Profiler1

Then we have to perform the desired actions in CRM in order to record the profle, before we can playback the recorded profile. The recorded profile is a sort of snapshot containing all the calls and values of the activity recorded in the plugin.

From the blog of the great Hosk, I got this quote:

Replaying plug-in execution does not require a connection to a Microsoft Dynamics CRM server and organization. The advantage of this method is that you can obtain the plug-in execution profile from a customer and debug the plug-in remotely. A restriction of the replay feature is that you cannot change the sequence of calls your plug-in code makes in the debugger while you are debugging.

The replay feature provides the plug-in with a snapshot of the call data and event execution context from the Microsoft Dynamics CRM server. You are getting the same events, GUIDs, and so on from calls to the Organization service but no data is being modified on the server as you debug the plug-in. During the debugging procedure in the previous section, the plug-in actually connects to the server and makes calls in real time.

I hear you think!  This is awesome!

Well sort of, actually in a lot of cases it is. You can replay the actions as often as you want. No data is saved to CRM (this is great), however…. the data during the replay is fetched in real time from CRM. * uh oh *

This caused me a big headache last week in which I had to resolve a bug on a plugin in which I had to update a field of an entity.
During the replay of the profile I saw data being fetched from CRM and put into a field of the entity. Once the plugin finished the execution, the data I put in the field was not saved. I was baffled!

How was this possible?

Putting trace statements in the plugin finally lead me to the solution. It turned out that in my case I was assuming that an association between two records was already in place; in fact it needed to be created at that point of time. While replaying the profile the association was already in place, resulting in a value (while at the real point of time, there was no value).

In my eyes, the behaviour of the plugin profiler is not correct. The plugin profiler should never make calls in real time to CRM. By making the calls to CRM, the data you see during the replay of the profile does not represent the data in CRM at the point of time of the plugin execution. This can be a big pitfall!

I Learned a valuable lesson the hard way: don’t never ever trust blindfolded the data you see in the plugin profiler! The data is being fetched in real-time!

As long as you keep that in mind, the tool can be pretty useful!  😛

2 thoughts on “Debugging 101: The Pitfall of the plugin profiler

  1. Kenny Vaes says:

    Also be carefull with any update, create and delete statements that might be part of the plugin’s code. As you stated, these calls are sent to the CRM instance that is connected to the plugin registration tool.

    So if this is your production instance, the records will be created outside of any transaction and will be committed to production. At least this is how the older versions of the profiler worked. I didn’t get a chance yet to test it with the newer one.

    I also learned the hard way 🙂

    • Thank you for sharing. I think in this area Microsoft needs to make some additional steps.
      I would love to see an option in which you could connect with the Visual Studio debugger directly to the CRM online instance (having it attached automagically to your sandbox processes)

      Bas

Leave a Reply

Your email address will not be published. Required fields are marked *