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.
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 file name 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.
One thought on “Great Reasons to Register your Plugins in Database Instead of Disk/GAC”
Special thanks to (email@example.com) for exposing my cheating husband. Right with me i got a lot of evidences and proofs that shows that my husband is a fuck boy and as well a cheater ranging from his text messages, call logs, whats-app messages, deleted messages and many more, All thanks to (firstname.lastname@example.org), if not for him i will never know what has been going on for a long time. Contact him now and thank me later.