The CRM Grid – A Microsoft CRM Blog

Greg Owens’ rose-tinted MS-CRM mumblings

Archive for August, 2008

Mail merge with CRM Web Client fails – cannot find data source

We ran into an issue last week where attempts to mail merge (specifically the “Print Quote for Customer” button) were failing. CRM would provide a Word document for download, but opening the document resulted in a warning:

Opening this document will run the following SQL command:

This message was followed with… no SQL command. Clicking on “Yes” to continue, presented the message:

Mail_Merge_<random numbers>.doc is a mail merge main document. Word cannot find its data source, .

Mail_Merge_.doc is a mail merge main document. Word cannot find its data source, .

No matter which templates were selected or which permissions were granted, the same error occurred.

This seemed to happy with machines that had the web client only (unconfirmed, but I believe this does not happen with the Outlook CRM client) and Office 2007 SP1.

A call to Microsoft support has verified that this is known issue, albeit undocumented for the public. It seems that Service Pack 1 for Office 2007 introduces an issue for mail merging from the web client. Apparently a hotfix is in the making but this is not being considered as a high-priority fix.

If you know of any workarounds let me know. If you have the problem yourself, get in touch with Microsoft and let them know so we can get a hotfix moved up their to-do list!

Debugging plug-ins in v4.0 (Updated)

(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 on how to debug CRM plug-ins remotely.