One of the main problems with plugin development is that we have a very limited set of debugging techniques. We can use the Tracing Service, but it’s not, really, debugging.. It’s tracing. We can keep throwing errors from the plugin, but that’s just another form of tracing. We can use a plugin profiler, and that comes very close to debugging, but we have to install the profiler, have to capture the log, and have to believe we are looking at the right log. And that’s still not debugging of the original execution – it’s a debugging of the replay execution.
Those are all useful techniques, but, personally, I find it very helpful to think of plugin development as of a special kind of development exactly because of the lack of debugging tools. Basically, you want to do as little debugging as possible, so, ideally, any code you are testing should be obvious and clear enough for you to be able to fix it without having to use debugging tools.
In other words, it’s all about that old well-known “divide and conquer” principle. When working on a plugin, keep dividing the functionality into very small pieces, then start adding those individual pieces to the code, but don’t go to the next piece until the current one has been tested.
You want to do it line by line? Not a problem, whatever suits you.
For example, imagine you have to write an on Update plugin to check organization credit limit against some pre-configured setting, so, basically, you need to do this:
- Get attributes from the plugin context Target
- Run a query to retrieve pre-configured maximum
- Do the comparison and throw an exception if required
If you write the whole plugin from top to bottom, you will likely have at least a few errors there, and you may have to debug your plugin to find out what went wrong.
If you did it in the “divide and conquer” way, you might do this:
- Create a basic plugin with no functionality, deploy it in Dynamics
- Add the code to get attributes from the target, use InvalidPluginExecutionException to quickly ensure that you got correct values, run a few tests (all values there, some values missing, etc)
- Add code to run the query, use InvalidPluginExecutionException to ensure you have retrieved the right value from the query (again, try different scenarios to make sure it works as expected)
- Finally, do the comparison and test the whole plugin
This may look like an overhead to a .NET developer who is used to debugging their apps in the Visual Studio, but that’s also the main reason I rarely need to use debugging tools when developing plugins, and that, in the end, simply saves me quite a bit of time.