Monday 7 May 2012

Xrm plug ins beyond the template

We're writing a fair bit of code for Dynamics CRM  at the moment. The team I'm working with have been cutting and pasting code found on Google onto the Visual Studio templates, then losing an awful of of time when things go wrong.

I'm completely new to Dynamics CRM and have been keen to learn, but I'm not used to such faith oriented software development. I'd rather poke around, fix stuff that looks stupid and start to better understand what's going on.

To cut what could be a long story short, I've landed up with a little library of extension methods, entity wrappers, etc to make my code more expressive and my life much easier  I'm going to write about some of these in later posts.  

This library of code has grown to the extent that I really wanted to put this stuff in a common assembly. I followed the ILMerge post from Chris Condron which is pretty easy, as long as you download the project attached to the post. While I was there, I decided to Create my own, generic IPlugin implementation, because the one that is generated as part of the Visual Studio integration is a pretty poor piece of code.

At this point I tried to build and deploy my plugin, with little expectation of success.  It took a bit of fiddling to get the ILMerge step to work.  My first issue came from my attempt to include an assembly compiled for Silverlight.  This is a correct thing to do, but a bad idea with ILMerge, which just sits there and thinks about the problem for a very long time.  I probably went too far while trying to understand the nature of the problem and added too many /lib: /closed and other switches, before finding that Chris's example works fine, as long as I only marked the common assembly as requiring merging.

I then ran into the deployment problems. CRM unhelpfully returns the same "Plug-in assembly does not contain the required types or assembly content cannot be updated" message whatever the issue. It looks like this could mean:
  • Your plugin is replacing another, but doesn't implement all of its steps.
  • An assembly required by the plugin is missing from the target server.
  • The plugin class does not directly implement IPlugin.
It turns out that I should have found Orangegeko's post about this, but I didn't.  Your class may well inherit from a class which implements IPlugin, but your class  has to explicitly implement IPlugin too.  The team who wrote this deployment process may want to consult some reflection documentation.

Having done all this, I now have a plugin class 40 lines long, compiling into a 20K or so assembly and a library with some unit tests.  I now feel like a developer again, rather than somebody trying to copy and paste solutions together.