Plug-ins can be register with Microsoft Dynamics CRM 2011 and Microsoft Dynamics CRM Online programmatically by writing custom code using SDK classes. However, to ease the learning curve and to speed up development and deployment of plug-ins, a sample plug-in registration tool with complete source code is included in the SDK download. By using this tool, you can concentrate on learning plug-in development first and then develop your own custom registration tools later, if desired.
|When plug-ins are registered in Microsoft DynamicsCRM, they become part of the primary operation of the Microsoft DynamicsCRM system. Do not register any plug-in unless it is obtained from a reliable and trusted source.|
For more information about how to package your plug-ins, see Package and Distribute Extensions with Microsoft Dynamics CRM Solutions.
In This Topic
Plug-in Registration Tool
Sample code for a plug-in registration tool is provided in the SDK\Tools\PluginRegistration folder of the SDK download. The tool provides a graphical user interface and supports registering plug-ins with Microsoft Dynamics CRM 2011 and Microsoft Dynamics CRM Online. You can also register assemblies containing custom workflow activities on Microsoft Dynamics CRM 2011 installations, but not on Microsoft Dynamics CRM Online, which does not support custom workflow activities. The source code for the application is provided to show you how to use the plug-in registration classes. For more information about how to register and deploy a plug-in by using the tool, see Walkthrough: Register a Plug-in using the Plug-in Registration Tool.
|To build and use this tool, you must install Windows Identity Foundation as described in the tools Readme file. To register plug-ins built using the 4.0 SDK you must use the Plug-in Registration Tool provided in the 4.0 SDK release.|
The tool can be added to the Visual Studio Tools menu as an external tool to speed up the development process.
Plug-ins not-registered in the sandbox can be deployed to the Microsoft DynamicsCRM server's database or the file system that is known as on-disk. We strongly recommend that you deploy your plug-ins in the Microsoft DynamicsCRM database, instead of on-disk, as the primary way to deploy production ready plug-ins. Plug-ins stored in the database are automatically distributed across multiple Microsoft DynamicsCRM servers in a data center cluster. On-disk deployment of plug-ins is supported for debugging of plug-ins using Microsoft Visual Studio.
Plug-ins registered in the sandbox must be deployed to the database.
When deploying a plug-in to the sandbox execution environment on Microsoft Dynamics CRM Online, the plug-in can only be registered and deployed to the database. On-disk plug-in deployment is not supported with Microsoft Dynamics CRM Online.
For on-premises or internet facing Microsoft DynamicsCRM installations, when you deploy plug-ins from another computer to the Microsoft DynamicsCRM server disk (on-disk deployment), the plug-in assembly must be manually copied to the server before registration. The assembly must be deployed to the <installdir>\Program Files\Microsoft CRM\server\bin\assembly folder on each server where the plug-in is to execute.
Plug-in registration should be done after the assembly has been copied to the \bin\assembly folder on the server to prevent the situation where a system user causes an event in Microsoft DynamicsCRM to be raised but the registered plug-in assembly does not yet exist on the server. For server database deployment, the plug-in assembly is automatically copied during plug-in registration so that the earlier situation is not an issue.
Depending on your plug-ins design, your plug-ins may require other referenced assemblies to run. Regardless of whether you deploy your plug-in to the database or disk, if your plug-in requires other assemblies to run, you must put copies of these assemblies in the Global Assembly Cache (GAC) on each server where the plug-in is to execute. Of course this does not apply to a Microsoft Dynamics CRM Online server since you do not have access to the GAC on that server. In that case your plug-in must not require other assemblies.
There is a security restriction that enables only privileged users to register plug-ins. For plug-ins that are not registered in isolation, the system user account under which the plug-in is being registered must exist in the Deployment Administrators group of Deployment Manager. Only the System Administrator user account or any user account included in the Deployment Administrators group can run Deployment Manager.
|For non-isolated plug-ins, failure to include the registering user account in the Deployment Administrators group results in an exception being thrown during plug-in registration. The exception description states "Not have enough privilege to complete Create operation for an SDK entity."|
The system user account under which the plug-in is being registered must have the following organization wide security privileges:
For plug-ins registered in the sandbox (isolation mode), the system user account under which the plug-in is being registered must have the System Administrator role. Membership in the Deployment Administrators group is not required.
Register Plug-ins Programmatically
The key centity types used to register plug-ins and images are: PluginAssembly, PluginType, SdkMessageProcessingStep, and SdkMessageProcessingStepImage. Use these entities with the create, update, retrieve, and delete operations. Refer to the Plugin Registration tool source code for sample code on using these classes.
For more information, see Understand the Data Context Passed to a Plug-in.
ConceptsPlug-in Isolation, Trusts, and Statistics
PluginAssembly Entity Privileges
PluginType Entity Privileges
SdkMessageProcessingStep Entity Privileges
SdkMessageProcessingStepImage Entity Privileges
SdkMessageProcessingStepSecureConfig Entity Privileges
Introduction to Solutions
Other ResourcesPlug-in Development
Security Role and Privilege Reference