6 Great Reasons to Register your Plugins in Database Instead of Disk/GAC

I decided to post this article since I am hearing quite often about developers using Disk and GAC for registering the custom plugin assemblies in CRM 2011. I have also heard claims such as “you must register on disk in order to debug” or “it is easier to update the assembly version when they are stored on disk” which I will do my best to disprove.

1. Only database assemblies can be packaged in solutions

Solutions are the future of CRM and Microsoft is not supporting packaging disk/GAC assemblies in solutions. Such statement almost suggests that GAC and disk are legacy registration modes, and moving forward only database should be used. Take advantage of being able to export, transport and import your plugin in a solution by registering it on database.

2. Zero service interruption to update a database assembly

If you register your assembly on disk or GAC and you would like to update it, you might be aware that even after the file is overwritten, the changes will not take effect until you do an “iisreset” which will cause down-time to your organization. Additionally, you must consider whether the plugin is asynchronous in which case you must also restart the CRM Asynchronous Processing service. Besides the down-time, there are also a number of manual steps to restart the services that you would probably want to avoid. If you register on database, all you need to do is click on “update” using the Plugin Registration Tool and update the assembly content.

This is indeed just as fast (if not faster) than drag-drop-replace but you won’t need to restart the services because the new assembly will take effect immediately after the update! The reason why you don’t need to restart the services is that the assembly loading routine from the bytes works different in .Net. When loading from GAC or disk, the assembly is loaded in the AppDomain as is never loaded again until the AppDomain or process is restarted. Note that if you plan to debug the assembly, you still need to copy the symbols to disk (symbols cannot go in database) and you can debug as usual.

3. Simplified organization backup / import.

If your plugins are registered on disk/GAC then backing up the organization database will not be enough. You will need to also backup all the custom assemblies you might have in the GAC or in disk. When you import the organization then you must also remember to copy those dll’s back into the new server(s). However, if you use database assemblies you only need the database backup and forget about tracking down these custom assemblies in order to restore your organization.




4. Disk assemblies will not support multiple versions

In CRM 2011 there is support for assembly versioning so you can have multiple versions of a given assembly coexisting in the system. For example, the workflow designer lets you select which version of a particular assembly for a custom workflow activity you would like to use:

Because both versions of the assemblies would have the same filename then you cannot register them simultaneously on disk.



5. All assemblies consolidated into a single place

With database assemblies another good thing is that they are all stored in a single place: the database. You don’t need to worry about deploying dll’s to file and GAC in multiple servers. If your CRM deployment is spread out in different server roles for load balancing, then you don’t have to worry about which roles will need your assemblies and on what servers you must deploy which assemblies. It can be really cumbersome with disk/GAC assemblies as you can easily lose track for example of which plugins run asynchronous vs. synchronous so they must be deployed to the web and async servers respectively.



6. Sandbox and CRM Online only support database assemblies

If you have your assemblies registered on database, you could include them in a solution. Therefore, you can easily migrate to CRM Online by exporting/importing the solution and you can mark your assemblies as sandboxed. You would not be able to sandbox your assemblies for disk/GAC and you would not be able to package them to migrate to CRM Online.