Register CRM 2016 Plugins and Steps Programmatically

Gayan Perera, 03 March 2016

We recently needed to programmatically register plugin assemblies and steps into a Microsoft CRM 2016 system. The registrations are done using the standard Create SDK calls. There are no need to call/execute any special requests against the Dynamics CRM API.

Few things to note, you’ll need to execute these steps in order to register plugins and steps dynamically.

1. Create a record of type “pluginassembly”
2. Create a record of type “plugintype”
3. Create a record of type “sdkmessageprocessingstep”

Creating the pluginassembly record

The pluginassembly record require quite a few fields to be registered successfully. We’ll assume that you already have a plugin that you’d like to register and that, that plugin can be registered successfully via the Plugin Registration Tool. This is to ensure you won’t run into random trouble around the plugin by not having a strongkey, a sample plugin with an execute method etc.

First step is to dynamically load the assembly using reflection. We do that by using Assembly.LoadFile. This will allow us to dynamically grab the plugin information such as, the name, culture, version, publickeytoken.

Next we need to specify where we would like to store the plugin, e.g. database or disk. We recommend that you use the database option.

Once that’s done, we need to specify the isolationmode, e.g. sandboxed or none. We recommend that you use the sandbox mode unless it is a must…using the sandbox mode ensures the plugins are compatible with the CRM Online environment.

Creating the plugintype record

A plugintype record must be created for each plugin inside the assembly. This can be done dynamically using reflection, for the purpose of this blog let’s have a look at a simpler example.

Firstly we need to link this plugintype record to the pluginassembly record that was created in the above step. The next piece of information that this record need is the typename.

The type name is the plugin class name. e.g. If you have a plugin called “SayHello” inside the namespace “Abc.Plugins”. The typename should be set to “Abc.Plugins.SayHello”.

Creating the sdkmessageprocessingstep record

Final step is to create a record for each of the messages you’d like to hook into. There are a number of attributes that must be set correctly in order for this to work. Similarly to the plugintype record, you must now ensure the step record is pointing at the correct plugintype record.

To specify the message you’d like to hook into, the guid of the message is required. To get the id/guid of the message you can query the sdkmessage entity using a QueryExpression or FetchXml.

To specify the entity that this plugin will run on, set a value for the sdkmessagefilterid attribute. If a value is not provided then this plugin will run on any entity. To get the id/guid of the sdkmessagefilter, simply query the sdkmessagefilter entity using a QueryExpression or FetchXml, filter by the sdkmessageid and primaryobjecttypecode. The primaryobjecttypecode is the schema name of the entity. e.g. account or “xyz_somecustomentity”

Other attributes such as name, configuration, mode, rank, stage, supporteddeployment, invocationsource are outlined above with comments and can be set based on your requirements.

The Dynamics CRM API will throw detailed errors if any of the above combinations of configurations/attributes don’t align. e.g. trying to register a plugin on the Won message for an account…