(Updated 9th June 2009)
As you will know, the extensibility model for Microsoft CRM has changed in v4.0 and we now have a concept of plug-ins (instead of the callouts that were used in v3.0).
I’m not a particularly seasoned C# developer but having got a comfortable grasp of the language, I was struggling when it came to debugging my plug-in. I knew the general principles of debugging and thanks to the plug-in registration tool, could get my code to fire, but I couldn’t get it to debug. I can now and here’s what I did (note – no revelations here, I’m simply writing this for the benefit of other n00bs).
Please note, I still use Visual Studio 2005. I haven’t done this in any other version so there’s no point in me trying to write about it – please comment if you have and whether these steps differ.
- So you’ve finished coding and are ready to deploy your assembly. Step one is to build your project via the Build… menu in VS.
- Next you need to deploy your assembly to the development server. You’ll need to use the Plugin Registration Tool to do this. I usually opt to deploy to the database as this avoids me having to deal with “file in use” errors (see below).
- In addition to deploying your assembly you must also place the debug symbols (.pdb file) in …\Program Files\Microsoft CRM\Server\bin\assembly. Once you’ve built your solution in Visual Studio, ensure that the latest copy of the .pdb file (look in your solution’s build directory) is copied to the aforementioned directory. Every time you (re)build your assembly you must copy the revised pdb file across.
- After copying the pdb file, you’ll need to restart IIS using the iisreset command from the command prompt. This is required so that the symbols can be read in (this step is also necessary sometimes in order to avoid “file in use” errors if you choose to deploy your assembly dll to disk) . I usually add an iisreset command into my Post-Build script in Visual Studio, along with an xcopy command, to move the pdb file to the correct location after each build.
- After running iisreset, you need to effectively “kick start” the CRM thread by simply opening or refreshing any CRM page. This ensures that the w3wp process is available for the debugger to attach to.
- The next step is to load your solution file up on the server. This of course requires Visual Studio to be installed on the development server. There may be alternatives to this approach (perhaps remote debugging or a test harness – see below) but I haven’t tried them.
- With your solution open on the server, select Debug > Attach to Process and then select the w3wp.exe process from the the list. You may need to place a check in the “Show Processes from all users” and “Show processes in all sessions” in order to see w3wp.exe.
- If you haven’t already done so, add some breakpoints to your code in VS by moving the cursor to the code you wish to break on and pressing [F9]. A red dot should appear in the margin.
- Finally, go to CRM and do whatever is required (as per your plug-in registration) to fire your plug-in (i.e. create/delete/update an appropriate record)
- The code should fire and reach your breakpoint in Visual Studio. You can step through the code a line at a time by press [F11] to advance to the next statement.
You might also be interested to hear that Akezyt Janedittakarn wrote on the MSCRM Team Blog about steps to aid the debug process using a test harness
I’ve just found this article at sadev.co.za on how to debug CRM plug-ins remotely.