CRM 2011: Debugging Server Side Code (Plugins)

Creating and debugging plug-ins can be one of the more annoying tasks in CRM 2011, and from my experience actually deters people from creating plug-ins where appropriate and people end up making oData calls in JavaScript on Forms instead. So I figured I’d do a quick write-up on debugging plug-ins. If you’re working on premise it’s a pretty simple task. Open up the solution with your code in Visual Studio (any recent version will work), click on Debug in the top toolbar then click Attach to Process…

Next, make sure the ‘See Processes from All users’ box is checked. This might not be necessary based off the account you logged in as, but it can’t hurt. You don’t have to change the Transport or Qualifier options. Finally, select the w3wp process. ‘Attach To’ should change to the .NET version of your solution.

Once attached, Visual Studio should stop at any breakpoint entered in your code as soon as that line is hit. Now if you’re not debugging / coding on the same box that CRM has been deployed to it’s a little more complicated to debug. Thanks to updates in the Plugin Registration tool and the introduction of the Plugin Profiler though, it’s easier than it used to be. First, fire up the Plugin Registration tool and connect to your CRM instance.

Once connected, click on the Profiler in the top toolbar.  Once installed it’ll show up as Uninstall Profiler as shown below.  Additionally you’ll see the new option of Debug:

Once installed, click on the step that you want to debug. A new button called ‘Profile’ will appear in the toolbar. Click on that, and (Profiling) should appear next to the step that you had selected:

Now do whatever will fire off this plugin. When you do that, the UI will respond with a pretty ugly message, this is ok and expected. When this happens, click on the Download Log button and save the text file somewhere easily accessible as we’ll need it in the next step. Also note that whatever you did in the UI will NOT be saved to the database:

Now go back to the Plugin Registration tool. Click on Debug. In the box that comes up, set the Profile Location to the text file that you just saved and set the Assembly Location to be the DLL of your compiled plugin. The Plug-In value will probably be automatically selected, but if not set that as well. Next, in step 3 you’ll see a line telling you what process to attach to. As we did earlier in attaching to the w3wp process, this time we’ll be attaching to the Plugin Registration process. So for example, in the screenshot below I’d attach to process 6164:

Once attached, click on the Start Plug-in Execution button in Plugin Registration. What will happen is that the data/action you just did in the UI will be re-done and Visual Studio will stop on any breakpoints in the code you that added, again very similar to what happened in the first example in this post. Another good part about this method is that if you need to run the same steps over and over, you can just re-run the trace. No need to enter the same information into the UI over and over.

From personal experience, I’ve noticed that some versions of the Profiler / Plugin registration play better with CRM than others. You might have to try different versions of the SDK to find one that works well for you. If you get some ugly error message, I’d start there.

If you’re using CRM as a platform for deploying line of business applications, make sure you’re getting the most from your investment by reading CRM Governance: What It Is, What It Isn’t, and How to Do It Right, an informative eBook written by governance experts.

Leave a Comment