Friday, 11 February 2011

Plugin Deployment Options

The CRM 4 SDK gives some information about the storage options when registering plugins but there are a few more considerations. I got prompted to elaborate on this in a forum post, and I think it's worth documenting this here as well:

The 3 storage options are: Database, Disk and GAC. The main differences between these are:

  • Database: The assembly dll is stored in the database, rather than the file system. The major advantages are that the assembly need only be deployed once if you have multiple CRM servers, and that no additional action is required to restore / redeploy the assembly either during disaster recovery, or if redeploying to an alternate server. This is the preferred option in a production environment
  • Disk: The assembly dll is placed in the \server\bin\assembly directory on each server. You have to ensure the dll is placed in the correct place on all CRM servers, so the deployment overhead is a little greater. I normally use this option in development environments as you can redeploy newer versions solely by file transfer, rather than reregistering. Also, if debugging, the assembly .pdb file needs to be placed in the same location; with this option it's easy to ensure the dll and pdb are from the same build
  • GAC: The assembly is placed in the Global Assembly Cache on each CRM server, and again you will have to do this. The GAC does allow multiple versions of an assembly, but CRM doesn't, so you don't really gain anything by using the GAC. I don't think I've ever used this option

There is one further consideration. If your plugin assembly has other dependent assemblies, then you can place this dependent assembly in the GAC whichever of the above options you take. However, if you use the Disk option, then the dependent assemblies can also be deployed into the \server\bin\assembly directory


ChrisS said...

Thanks for the info.

thecrmgrid said...

In terms of dependent assemblies, I have preferred the option of merging those dependencies into a single "MyMergedPlugin.dll" which facilitates the deployment (in my opinion) by leaving you to only consider the relative merits of the three deployment options you have listed.

As I'm sure you will already know (but I mention for anyone else reading) Microsoft's "Ilmerge" ( can be called as a post-build event on your plug-in solution and roll all the dlls up into one, eg:

"%PROGRAMFILES%\MICROSOFT\ILMERGE\ILMERGE.EXE" /keyfile:"$(SolutionDir)\mykey.snk" "$(TargetDir)dependency1.dll" "$(TargetDir)dependency2.dll" "$(TargetDir)MyBasicPlugin.dll" /out:"$(TargetDir)MyMergedPlugin.dll"

David Jennaway said...

thecrmgrid, thanks for the comment. ILMerge is a valid option, and it's one I'd take if there were no other options (e.g. deployment onto an external CRM service provider).

However, my view is there's normally a good reason why the code was developed as separate assemblies (e.g. to permit independent deployment and versioning), so I generally prefer to deploy dependent assemblies as is in the GAC

hoskinator said...

great article. Often when people begin with CRM plugin's it can seem a bit confusing to have these three options but you have explained the choices nicely.


lee woo said...

The more we exploit nature, The more our options are reduced, until we have only one: to fight for survival. See the link below for more info.


Silvia Jacinto said...

I am very happy to visit your site and i did like it. I was able to get some informative topics. keep it up and you can also visit my site for your reference. Thank you and have a good day.