Developers can add additional business logic to Microsoft Dynamics CRM 2011 by writing custom plugins and registering them to the appropriate steps. However, debugging plugins can be quite a tricky task for developers especially when working with complex business logic. In this post, I will show you some simple techniques you can use to debug your Dynamics CRM 2011 plugins.
Throwing the InvalidPluginExecutionException
When writing a complex plugin that can follow different paths of execution, I like to throw a “dummy” exception just to make sure that a certain condition of an if-statement is being hit. When we re-register the plugin and then perform an action to trigger the plugin, we can determine if our if-statements have been written correctly if CRM pops up an error. The following syntax can be used to throw the exception:
throw new InvalidPluginExecutionException("your message here");
Be careful not to leave any dummy exceptions within your plugins!
The ITracingService
The ITracingService allows developers to write information to a log file which is then presented to a User should an error occur. We need to make sure that we have try/catch blocks in place or that we throw the InvalidPluginExecutionException so that an error pops up in CRM and allows the User to download the trace file to see what’s going on. For example, I recently had an issue with empty date fields in CRM running inside a plugin which needed to set another date. I had not included the appropriate null checks, therefore the resulting date was considered “unrepresentable”. I was then able to use the following line of code to write the date to the trace file in order to view the result:
_tracer.Trace("date is {0}", date);
This is a much nicer way to handle tracing than what I was used to in Dynamics CRM 4.0. I would use a StreamWriter object to handle tracing, however this is only useful for on-premise implementations where we have access to the log file being written.
Using Console Applications
Some CRM plugins might involve complex calculations involving multiple fields from multiple related entities. Personally, I find it easier to convert the plugin logic into a Console Application which can run locally on my machine. The Console Application will need to be written so that it retrieves the appropriate record(s) from CRM so we can ensure we are using accurate data. I can then use the debugging tools provided within Visual Studio to step through each line of code and view the result of any calculations, make changes, and then include the logic within the actual plugin code once I am satisfied it is working. Of course it then requires re-testing within CRM!
I hope that these techniques are of some use when you are developing your own plugins for Dynamics CRM 2011. They have definitely helped me debug custom business logic and have proven to be time savers for me with projects I have been working on.
Image 1 from: http://thecustomizewindows.com/wp-content/uploads/2011/02/no-bugs.png