This is a blog about my experiences with Microsoft Dynamics CRM, tips and tricks as well as news from the CRM community.

Thursday, June 2, 2011

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.

6 comments:

I really only put a plugin on disk if I want to remote debug it because you then need to put the dll and the pdb file on the server.

You can also have problem copy over the file, I had to shut the server down to copy over the dll today.

other than that I agree with all the reasons you mention and always deploy the plugin to the database. Another benefit is it will work with load balanced servers but if you put it on disk you would have to copy the dll to all your servers. I think I remember a question about that topic on the Extending CRM 4 exam

Are you sure you cannot remote debug if the assembly is registered on database? I don't see why not...As long as you copy the symbols to the server\bin\assembly they will be loaded by the w3wp process.

Super, until now I always use the db for the plugin registration for the reasons mentioned. But what about referenced dll's. Until now I created a separate installer and installed the dll's to the GAC but that's causing some other issues now. I tried to copy them to the server\bin\assembly folder of CRM (2011) but the plugin fails and it's telling me that it can't find the references.Any idea's what to do?

About me

I used to be part of the CRM product team at Microsoft and I recently joined the Avanade Canada team as a consultant in the CRM Service Line, I developed a sort of delight in seeing how Dynamics CRM is evolving as a platform (xRM) and how its feature set has matured to be able to model and address plenty of business scenarios beyond Customer Relationship Management. I was recently given the Microsoft MVP award in Dynamics CRM and I am really excited to be part of the program and continue contributing to the CRM community.