One of the main challenges surrounding the development of plugins for Dynamics CRM, is the difficulty in debugging errors. There are many ways to debug your code, such as checking the event viewer for any exceptions thrown, check the associated system jobs within the CRM UI, making use of the “ITracingService” within your code etc.
But the most powerful way to debug your code is to attach the remote debugger to the correct service on the CRM Application server. Below are the steps required to achieve this:
- Install the required version (depending on which version of Visual Studio you are running) of Visual Studio Remote Tools on the CRM Application Server.
- If you haven’t already, register your plugin using the plugin registration tool provided in the Dynamics CRM SDK. (IMPORTANT: The plugin must be registered as “Disk”, if you have already registered in the GAC or Database, re-register your plugin as Disk, and once you have finished debugging, re-register it to what you require.)
- Once registered you must place the .dll and .pdb files of the plugin (IMPORTANT: The version of the code must be identical for this to work) and any other .dlls required by your plugin in the assembly folder within the Dynamics CRM install directory on the Application server. e.g C:\Program Files\Microsoft Dynamics CRM\Server\bin\assembly
- Within Visual Studio, place a breakpoint where you require to debug your code, and then click “attach to process” under the debug menu in the toolbar.
- Select the correct Qualifier (This should be shown at the top of the Remote Debugger Window) and make sure that the “Show all processes from all users” box is ticked.
- Select the correct process to attach the debugger to:
|Asynchronous or Custom Workflow Step
7. Perform the action to which your plugin was registered, and your break point should be hit within Visual Studio, allowing you the ability to debug through your plugin.
If you wish to make a change to your code and then continue debugging, follow the steps below:
- Make the changes your code and rebuild the solution to regenerate the .dll and .pdb files.
- On the application server, restart the service process your plugin is running under and reset IIS by typing “iisreset” into cmd.exe.
- Replace the old .dll and .pdb files with the new ones.
- Reregister your plugin assembly using the plugin registration tool (outlined in Step 2 at the top of the page)
- Reattach the debugger. (as outlined in steps 4 and 5 at the top of the page).
- Perform the action required to execute your code again.
- The SDK version of some .dlls (Microsoft.xrm.sdk.dll, Microsoft.xrm.sdk.workflow.dll etc.) referenced in a plugin being different from the rollup version on the App Server can cause issues in your plugin which can be found while debugging. Make sure that the version of these .dlls are compatible with the rollup on the server. These .dlls can also be placed in the assembly folder alongside your custom .dlls and .pdb files if they are referenced in your custom .dll to resolve this.
- Make sure the Remote Debugger is running with Administrator privileges to avoid the following error:
“Unable to attach to the process. The Visual Studio Remote Debugger (MSVSMON.EXE) has insufficient privileges to debug this process. T0 debug this process, launch the remote debugger using ‘Run as administrator’. If the remote debugger has been configured to run as a service, ensure that it is running under an account that is a member of the Administrators group.”
If you need any further information then get in touch.
3. Remote Tools for VS2013 –
4. MSDN Article on remote debugging –
Tags: Bridgeall, CRM, Development, Dynamics CRM, it development, Microsoft, Software Development, system testing