Part 1 – Setting up Visual Studio Project
Pre-Requisites
Here’s what you need to be have installed in order to proceed to writing a plugin –
- Plugin Registration Tool – Required for your to connect to the Dynamics 365 environment and deploy your plugin on.
How to get Plugin Registration Tool: Download Plugin Registration Tool for Dynamics 365 CRM using PowerShell - Microsoft Visual Studio – You’ll need to write your plugin in a Visual Studio IDE as it’s the preferred way to code your plugin and also to Version Control / Source Control.
Scenario
Now, before you decide why you have to write a plugin, it is presumed that you have some high-level understanding as to why you are writing this plugin.
To keep it short, here are some points –
- Understand Plugin Execution Pipeline (Basically, it means when is the plugin supposed to run when you perform a certain operation) – https://carldesouza.com/dynamics-365-plugin-execution-pipeline/
Example Business Scenario
Here’s a quick example we’ll consider which we will implement using a plugin –
- An account has a custom field called as Group Code.
- So whatever is updated in this field should be updated on all the Child Contact records under the Account.
Now, let’s write a quick plugin to implement this.
Writing a Plugin – Visual Studio
Given that you want to start writing a plugin, you must also have understood some concepts –
- You’ll need to create a new .NET Framework Project in order to get started. I use Visual Studio 2022 (This was newly released at the time of writing this post)
So the type of Project required is a Class Library of .NET Framework - Once you click Next, provide a relevant name to the Project. As a D365 Consultant working on multiple projects, you should be able to identify the library/assembly by the name as to which Org and what Module it belongs to.
In my case, I’m calling it CFT158SalesPlugins which is sufficient to give an idea of what org and what module this assembly is for. - Once I click on Create, an Empty Project with the standard Class1 will be created which will be ready for you to start writing.
- Next, since Dynamics 365 CRM plugins extend IPlugin interface provided by Microsoft Dynamics, you’ll need to fetch references for the same.
Now, right-click on the Project itself and click on Manage NuGet Packages… - Then, go to Browse and then search for Dataverse…
- You’ll find Microsoft.CrmSdk.CoreAssemblies which you can download. I usually choose a little older version than the current one.
- Make sure you have selected the correct one. Then, click OK.
Next, you get a chance to also look at the licensing terms before you Accept. Once you are OK, you can click on I Accept. - If you have the Output window open in your Visual Studio, you’ll be able to see the progress. It only takes a few seconds for the references to be imported.
- Once done, you can see that the references required have now been added to the project.
- I’ll rename my Class1.cs to something that gives an idea of what the Plugin would do.
So, for example, I’m setting it to AccountUpdate.
Detailed post on Renaming or Deleting a Plugin in Dynamics 365 CRM
Now, that my class is renamed, I’ll also add the references to the Class File so that I can use the IPlugin interface. In most common Plugin scenarios, you’ll need Microsoft.Xrm.Sdk amongst other references too.
My personal practice is to include as shown below –
Setting Initial Methods
Now, let’s set a template of which we can start to code the plugin. Before we do that, some common Methods need to be added first.
- I’ll now extend the IPlugin interface to the class.
- As you choose the IPlugin, in Visual Studio, you’ll be prompted for some actions which will auto-complete the interface process. Look for the icon on the left hand side and expand the menu to find Implement Interface
Once done, the Execute method will be populated as below. Execute method is the first method from where the plugin execution starts.
Also, make sure the class is public so that we can register is successfully in the Plugin Registration Tool. - Now, below are some helper methods which are required for the plugin to be registered on the environment.
You can copy from here:context = (IPluginExecutionContext)serviceProvider.GetService(typeof(IPluginExecutionContext));
service = ((IOrganizationServiceFactory)serviceProvider.GetService(typeof(IOrganizationServiceFactory))).CreateOrganizationService(context.UserId);
trace = (ITracingService)serviceProvider.GetService(typeof(ITracingService)); - In order to understand what these methods are, you can simply hover over these and read the definition. If you don’t understand these right away, it’s not a problem. But, it’s recommended that you thoroughly understand the purpose behind each of these.
- Then, this should be the first method to call in order to establish connection with the Dynamics 365 CRM organization you are hosting this plugin on.
- Next, you’ll need to Sign the Assembly before it could be registered on the environment using Plugin Registration Tool.
Right-click on the Project and then choose Properties. - Once in Properties, look for the Signing section on the left-hand side on the menu.
Notice that the Sign the assembly is not yet enabled. - Once you tick it, it’ll expose the area below and you’ll be able to create a new strong key name file.
- When I click on new, I created a strong name key file –
Note: I’ve not password protected the Strong Name Key I’m creating but it’s up to you to maintain it if needed. - Once I click OK, the .snk file will appear here.
- Finally, build the Project at this stage and we’ll move towards Registering this Plugin.
Now, at this point, we have established the code which is ready to be hosted on the Dynamics 365 CRM organization itself. Post this point, you’ll now code the logic which is supposed to be done by the plugin.
Part 2 – Registering your plugin
Log into Plugin Registration Tool
Based on where you have downloaded the Plugin Registration Tool, navigate to the folder and follow the below –
- Open the Plugin Registration Tool from the directory.
- Now, given that this is Dynamics 365 CRM Online (Customer Engagement / Dataverse) environment, you’ll make sure Office 365 is selected and then you’ll need to enter Admin Credentials.
- Once successfully authenticated, you’ll be asked to choose which organization this is in. Given that development should ideally be done on a Dev/Sandbox environment, you’ll select the appropriate environment here.
- Once logged in, you’ll see the the assemblies registered with the CRM environment. These are the out-of-the-box assemblies which are not supposed to be manipulated.
Register your Assembly
Let’s register the Plugin Assembly –
- Click on the Register New Assembly button and click on New Assembly
- You can now click on the three dots in order to navigate to the .DLL file which was generated when you Build the project.
- You’ll then need to navigate to the bin folder (Either Debug or Release)
- Once you select the .dll file, you’ll see the plugins which are exposed in the dll i.e. the Plugins of .CS of ‘public’ visibility.
Once this looks good, click on the Register Selected Plugins - Upon successful registration, you’ll see the below message.
- And your Assembly will now be registered successfully using the Plugin Registration Tool.
- In case this Project was not signed with .snk file, you’d see the below message.
“Assemblies containing Plugins must be strongly signed. Sign the Assembly using a KeyFile“
Now, the assembly has been registered. Next, we’ll add a step (you can call it a trigger for the plugin to start executing)
Register Step for Plugin
Now, let’s register a step for the Plugin –
- Now, given that the Assembly was successfully Registered, the next step is to Register a Plugin Step.
Expand the Assembly, then expand the Plugin itself to which you want to add a Step. - As per the scenarios from Blog 1, the plugin is supposed to be triggered on change of the Account’s field Group Code.
So, when you click on Register New Step, you’ll get to configure the Step
Here, Message means the “operation” on occurrence of which the Plugin should be triggered. In this example, we want to trigger the plugin on an Update operation.
Primary Entity denotes which entity is this targeted at. Account in this example.
Then, the Filtering Attributes is available if the Message is set to Update since Filtering Attribute let’s you select which all fields should be listened to in order to run/trigger the plugin. - Clicking on the three dots, you’ll get to choose the fields. In this example, we’ll select the Group Code field.
- Once you click OK after choosing what all fields the plugin should fire on, you should select “under whose security context should the plugin be running”
Run in User’s Context is that field to choose the user.
In my practice, I choose either Calling User or a System Administrator - Finally, I’ll choose “when in the context of the operation” should the plugin be triggered.
Since, I want the plugin to run “after” the “Update” operation is performed, I’ll select PostOperation.
And Execution Mode has options – Asynchronous / Synchronous defines if the plugin will run in the background or with the operation itself. - Once I choose these preferences, I’ll click on Register New Step and the Step will be registered on the Plugin.
- At this point, you’ve successfully registered the plugin assembly and a step on the plugin to be triggered on the update of the Account field – ‘Group Code’.
Part 3 – Adding Logic
Context of the PluginSince this plugin is registered on one of the common messages like Update, let’s capture the context of the Update record we are working on –