CRM Plugin Registration options explained

Someone was asking me this week about the different deployment options when registering Plugins in CRM.  It is my belief you can store the plugin to disk when you are developing the plugin, this will enable you to debug the file with pdb file.

When you registering the plugin on the live server then it’s better to register it in the database.  The main advantage is the code is safely stored in the database and is accessible to all the deployments e.g. offline/outlook as well as the main crm server.

Having the plugin in the database also makes it easier to update because a few times I have had problems updating plugin dll’s on disk because you have to copy over the exact dll and if you don’t it doesn’t always update the dll so CRM ends up using the previous version of the dll.

The database installation also means if the CRM server is load balanced over a few machines you only have to deploy it once to the database, where as if you installed it on disk you would have to install the plugin on all of the servers.

I have never used the GAC option, we have installed dll’s used by the plugin into the

I found this good post explaining the options.  It also had an interesting comment mentioning ILMerge, which you can download here, this is a .NET tool/utility which merges a number of dll’s into one dll, which is useful for creating plugins for online CRM.

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

 

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.