I’ve been watching the CRM Developer Toolkit since it was in CodePlex for CRM 4.0 and, while it had some nice features, it came at the price of requiring too many changes to my team’s methodology. With the most recent release in SDK 5.0.7 however, the toolkit has become a productivity enhancing add-on that I can’t live without. The CRM Solution template does a fantastic job of managing and deploying the Web Resources, Plug-ins, Workflows and Silverlight in my solutions. As great as it is, there are still a few pitfalls to watch out for so here is a list of do’s and don’ts when it comes to using the toolkit.


1. Only create Web Resources in CRM

The developer toolkit makes it very easy to add new Jscript files to your solution, so you may be tempted to do so, but there’s a problem here. Visual Studio doesn’t know about your solution’s provider prefix, so that gets added to the Web Resource when you deploy. This makes your solution appear out-of-sync with CRM since the file name in Visual Studio remains the same un-prefixed name you created it with. The safest and most consistent approach is to create new Web Resources in CRM and then use the Add to packaging project feature of the CRM explorer. This also works well if you want to start using the toolkit on an existing CRM solution.


Note: Microsoft has a recommended naming convention that includes slashes (/) in the resource names for Web Resources. This will cause an error ins Visual Studio when you attempt to import them, so you may want to consider that before using that approach.


2. Solution Deploy Updates Jscript – almost

If you make a change to a Jscript file in your solution and then deploy it, the changes will be sent to the CRM server as though you edited the Web Resource file directly, however you still must Publish the change before it will take effect. The same goes for other Web Resources like web pages, images and stylesheets. This is most efficiently accomplished by opening the Entity form in Visual Studio from the Entity Browser of the CRM Explorer.


3. Plug-in Creation and Debugging

The Create Plug-in wizard is reason enough to use the Developer Toolkit. All of the Messages for each Entity can be selected and depending on the Message and Pipeline Stage selected, the Pre/Post Image options become editable. The Select Attributes screen can even function as a rudimentary CRM browser!

If you do create an Image Alias, the plug-in class created by Visual Studio has code inserted to make your image available to you automatically:


When the wizard finishes, the plug-in class is created for you and is added to the RegisterFile.crmregister (make sure it is checked out before you start the wizard). If you need to make any changes to your plug-in’s registration attributes, you will have to edit the RegisterFile manually.

Another feature in the Developer Toolkit is the plug-in superclass.  All plug-ins created extend a new class that provides “helpful” context, tracing and event registration in the constructor. Take a look at the Plugin.cs file included in the Plug-in project for more details.

Debugging works well once you follow the setup instructions, though copying the PDB file remains a manual step. Also note, the sandbox process (Microsoft.Crm.Sandbox.WorkerProcess) is not started until after a plug-in is run, so you will have to invoke it (or another one) at least once before you will be able to debug.