Export (0) Print
Expand All
This topic has not yet been rated - Rate this topic

Register and Deploy Plug-Ins

[Applies to: Microsoft Dynamics CRM 2011]

You can programmatically register plug-ins and custom workflow activities with Microsoft Dynamics CRM 2011 by writing registration code using certain SDK classes. However, to ease the learning curve and to speed up development and deployment of custom code, a plug-in and custom workflow activity registration tool is included in the SDK download.

While this topic focuses primarily on plug-ins, most of the information is also applicable to custom workflow activities. One difference between the two is that for custom workflow activity assemblies, you register just the assembly. For plug-ins, you register the plug-in assembly and one or more steps per plug-in. For more information about custom workflow activities, see Custom Workflow Activities (Workflow Assemblies) for Microsoft Dynamics CRM.

securitySecurity Note
Do not register any plug-in or custom workflow activity unless it is obtained from a reliable and trusted source.

For more information about how to package your plug-ins as solution components, see Package and Distribute Extensions.

In This Topic

Plug-in Registration Tool

The Plug-in Registration tool provides a graphical user interface and supports registering plug-ins and custom workflow activities with Microsoft Dynamics CRM 2011. However, plug-ins and custom workflow activities can only be registered in the sandbox (isolation mode) of Microsoft Dynamics CRM Online. The ability to register custom workflow activities in the sandbox (partial trust) is new in Microsoft Dynamics CRM 2011 Update Rollup 12 and Microsoft Dynamics CRM December 2012 Service Update.

Beginning with version 5.0.13 of the SDK, you can find the tool’s executable file in the Bin folder of the SDK download. In previous SDK releases, you had to build the tool from source code provided in the Tools\PluginRegistration folder.

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. The tool can be added to the Visual Studio Tools menu as an external tool to speed up the development process.

Plug-in Storage

For an on-premises deployment, plug-ins that are not registered in the sandbox can be stored in the Microsoft Dynamics CRM server's database or the on-disk file system. We strongly recommend that you store your production-ready plug-ins in the Microsoft Dynamics CRM database, instead of on-disk. Plug-ins stored in the database are automatically distributed across multiple Microsoft Dynamics CRM servers in a data center cluster. On-disk storage of plug-ins is useful for debugging plug-ins using Microsoft Visual Studio but is mostly provided for backward compatibility with callouts. You can debug a plug-in that is stored in the database. For more information, see Debug a Plug-In.

Plug-ins registered in the sandbox must be stored in the database regardless of the Microsoft Dynamics CRM deployment (on-premises, IFD/SPLA, or Online).

Deployment

For on-premises or Internet-facing Microsoft Dynamics CRM installations, when you deploy plug-ins from another computer to the Microsoft Dynamics CRM 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 Dynamics CRM 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-in’s 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 on each server where the plug-in is to execute. This does not apply to a Microsoft Dynamics CRM Online server because you do not have access to the global assembly cache on that server.

To move a plug-in from a development environment to a staging or production server

  1. On the development computer, build the plug-in code. Do not include debug information. Optimize the plug-in for performance.

  2. Register the plug-in in the Microsoft Dynamics CRM server database.

  3. Using the Microsoft Dynamics CRM web application, create a solution or use an existing one, and add the plug-in to that solution.

  4. After you have added any other desired components to the solution, export the solution.

  5. Import the solution on to the staging or production server.

Assembly Versioning and Solutions

Plug-in assemblies can be versioned using a number format of major.minor.build.revision defined in the Assembly.info file of the Microsoft Visual Studio 2010 project. Depending on what part of the assembly version number is changed in a newer solution, the following behavior applies when an existing solution is updated through import.

  • The build or revision assembly version number is changed.

    This is considered an in-place upgrade. The older version of the assembly is removed when the solution containing the updated assembly is imported. Any pre-existing steps from the older solution are automatically changed to refer to the newer version of the assembly.

  • The major or minor assembly version number, except for the build or revision numbers, is changed.

    When an updated solution containing the revised assembly is imported, the assembly is considered a completely different assembly than the previous version of that assembly in the existing solution. Plug-in registration steps in the existing solution will continue to refer to the previous version of the assembly. If you want existing plug-in registration steps for the previous assembly to point to the revised assembly, you will need to use the Plug-in Registration tool to manually change the step configuration to refer to the revised assembly type. This should be done before exporting the updated assembly into a solution for later import.

For more information about solutions, refer to Introduction to Solutions.

Security Restrictions

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.

ImportantImportant
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:

  • prvCreatePluginAssembly

  • prvCreatePluginType

  • prvCreateSdkMessageProcessingStep

  • prvCreateSdkMessageProcessingStepImage

  • prvCreateSdkMessageProcessingStepSecureConfig

For more information, see Security Role and Privilege Reference and The Security Model of Microsoft Dynamics CRM.

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 entity types used to register plug-ins and images are: PluginAssembly, PluginType, SdkMessageProcessingStep, and SdkMessageProcessingStepImage. The key entity types used to register custom workflow activities are PluginAssembly and PluginType. Use these entities with the create, update, retrieve, and delete operations. For sample code showing the use of these classes, see the Plug-in Registration tool source code.

For more information, see Understand the Data Context Passed to a Plug-In.

Enable or Disable Custom Code Execution

You can use Windows PowerShell to enable or disable custom code, including plug-ins and custom workflow activities, on the server as described here. Alternatively, you can use the Deployment Web service. For more information, see Deployment Entities and Deployment Configuration Settings to set the CustomCodeSettings.AllowExternalCode property.

To enable custom code execution

  1. Open a Windows PowerShell command window.

  2. Add the Microsoft Dynamics CRM PowerShell snap-in:

    Add-PSSnapin Microsoft.Crm.PowerShell
    
  3. Retrieve the current setting:

    $setting = get-crmsetting customcodesettings
    
  4. Modify the current setting:

    $setting.AllowExternalCode="True"
    
    set-crmsetting $setting
    
  5. Verify the setting:

    get-crmsetting customcodesettings
    

To disable custom code execution

  1. Open a Windows PowerShell command window.

  2. Add the Microsoft Dynamics CRM PowerShell snap-in:

    Add-PSSnapin Microsoft.Crm.PowerShell
    
  3. Retrieve the current setting:

    $setting = get-crmsetting customcodesettings
    
  4. Modify the current setting:

    $setting.AllowExternalCode=0
    
    set-crmsetting $setting
    
  5. Verify the setting:

    get-crmsetting customcodesettings
    

See Also

Microsoft Dynamics CRM 2011
Send comments about this topic to Microsoft.
© 2013 Microsoft Corporation. All rights reserved.
Did you find this helpful?
(1500 characters remaining)
Thank you for your feedback

Community Additions

ADD
Show:
© 2014 Microsoft. All rights reserved.