Debugging a Dynamics CRM Plug-in

11.2k views Asked by At

I'm having trouble debugging a Dynamics CRM Online (2015) plug-in (C#). I'm following the instructions on this MSDN article to attach to a process. In the Attach To Process window, I select "Show processes from all users" and refresh. However, I don't see any of the four service processes listed (I think the plug-in type is "online" in my case).

  • w3wp.exe (while having the CRM Online instance open in IE)
  • Microsoft.Crm.Application.Hoster.exe
  • CrmAsyncService.exe
  • Microsoft.Crm.Sandbox.WorkerProcess.exe

I've already deployed and registered the plugin using the plugin registration tool. I've never done this before so I may be going about it the wrong way. Any ideas?

1

There are 1 answers

1
Nicknow On BEST ANSWER

Per the link you referenced, if you are working with Dynamics CRM Online you cannot attach to any of the CRM processes, since they are not running locally.

The first paragraph states (emphasis added by me):

The following steps describe how to debug a plug-in executing on Microsoft Dynamics CRM 2015 on-premises. To debug a plug-in that executes in the sandbox on Microsoft Dynamics CRM Online, you must using [sic] tracing as described later in this topic.

You will need to use the Plugin Profiler to Debug plugins executing in CRM Online.

From Analyze plug-in performance:

  1. Run the Plug-in Registration tool. You can find the tool’s executable file in the Tools\PluginRegistration folder of the SDK. Download the Microsoft Dynamics CRM SDK package.
  2. Click or tap CREATE NEW CONNECTION to connect to a Microsoft Dynamics CRM server and organization. For more information on connecting to a server and organization, refer to the SDK topic: Walkthrough: Register a plug-in using the plug-in registration tool.
  3. Register a plug-in and step on the Microsoft Dynamics CRM server. Keep a copy of the debug compiled plug-in assembly on the computer where you are running the tool.
  4. In the toolbar for the target organization, select Install Profiler. You will now see a Plug-in Profiler node in the list.
  5. Select a plug-in step and click Start Profiling in the toolbar to begin profiling. You can choose how the profiler executes in the displayed Profiler Settings dialog.
  6. Perform the operation in Microsoft Dynamics CRM that causes the plug-in to run. For example, if the step is configured for an update to an account, then update an account.
  7. If you have selected the Exception option in the Profiler Settings dialog, after the plug-in throws an exception and the Business Process Error dialog is displayed, click Download Log File and save this file. Alternately, if the plug-in does not throw an exception, click Stop Profiling.
  8. In the Plug-in Registration tool, click Debug.
  9. In the Debug an Existing Plug-in dialog box, provide the requested information in the Setup tab. Enter the location of the previously saved log file in the Profile field. Enter or choose the location of the plug-in assembly and the class name of the plug-in that was executed.
  10. Launch Microsoft Visual Studio and attach the debugger to the PluginRegistration.exe process.
  11. Set a breakpoint in the plug-in code.
  12. Click Start Execution in the Debug an Existing Plug-in dialog box.
  13. After a slight delay, the plug-in will execute using the same execution context that was passed to it by the Microsoft Dynamics CRM server and the debugger will stop execution on the breakpoint that you previously set.
  14. Continue debugging the plug-in as you would normally do. Any traces that the plug-in outputs are shown in the Debug an Existing Plug-in dialog box.

At this point you can alter the plug-in code, build it, re-attach the debugger to the PluginRegistration.exe process, and click Start Execution to continue with your debugging session. While performing these operations, you do not need to close the Debug an Existing Plug-in form.

You do not need to re-deploy the plug-in to the Microsoft Dynamics CRM server until after you have fixed the code problem. This debugging scenario works even if you have an optimized version of the plug-in on the server and a debug version of the plug-in on the computer where you are debugging.