The process used when developing plugins can have a major influence on efficiency. This post explains the process that I have found to work best for me.
The first step of the development process is to determine whether the plugin should be placed in an existing assembly or in a new assembly. Having multiple assemblies allows multiple developers to work in parallel, however, it also increases the code’s footprint.
It is also beneficial to consider how files are organized within the plugin. I have found it works well to organize plugins by the entities that they are registered on. It can also be helpful to leave the namespace as the assembly namespace (although ReSharper will complain). This allows the files to be easily reorganized without being in the completely wrong namespace when compared to the folder structure.
Also, when creating the plugin, inheriting from a base class can be helpful. This minimizes boilerplate code, making the plugin easier to understand and more standardized.
Exceptions and Plugin Profiler
When developers first start writing Dynamics plugins, they often insert Exceptions purely for use during the development process. They may write a trace after every line. Or, they may even use the Plugin Profiler. Although these can all be useful at times, they are not usually very efficient.
I have found the methods below have improved my development process.
To allow unit testing, I move the bulk of the plugin functionality into a separate function. Then, I make this function public so that it can be called from a unit test. When calling this function, it is often simplest to identify a record in CRM to test against and then pass in this record id along with an Organization Service connected to the development organization. However, if the plugin needs to support many varied and/or complex cases then I will instead use FakeXrmEasy to ensure that the various cases are sufficiently tested.
Plugin Trace Log
If an issue is difficult to setup, or an issue is only occurring when the plugin has been deployed to CRM, then it can be helpful to debug using trace statements. To do this, enable the plugin logging built into recent versions of CRM, and then view the Plugin Trace Log through the XrmToolbox Plugin Trace Viewer. This eliminates the need to install the plugin profiler solution and allows tracing without adding extra Exceptions to the plugin.
One more helpful tool in this process is the XrmToolbox Plugin Auto Deployer. This monitors the plugin assembly for changes and automatically updates the plugin in CRM when it is built within Visual Studio. When the plugin deployment tool is set to monitor the release build, the debug build can be used to work out most issues using unit testing without deploying to CRM. This also helps avoid interfering with other developers during development.
Let me know what works well for you in the comments below.