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 Plugin

Since 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 –

I’ll write a new method to just capture the context. If you are an expert in C#, you could smartly implement this than I have done. 😊
Here, once the service, context and trace are set, you can have a new method to capture the context.
In GetRecordContext() method, context.InputParameters[“Target”] will give you what is captured in the current Update context of the specific record you are running this plugin on.
Typecase it into Entity so that you can retrieve required values from Entity currentEntity .

Here, I’ve null-checked if the value is a part of the context update (in case the plugin unknowingly set to run on update of all fields), then I’m capturing the field value in a String variable to pass further.
Once I capture the field value, I’ll pass it to GetAllChilRecords() method
Next, in GetAllChildRecords(groupCode) method, I’m passing the updated string value further so that it can be updated to all retrieved child records.
Here, I’m using FetchXML query to retrieve the Contacts which have the Company Name field i.e. the Account lookup set to the current record (current Account record on which we are updating the Group Code field)
Quick Post on FetchXML attributes: Get all attributes in FetchXML in Plugins | Dynamics 365 CRM [Quick Tip]

Now, there’s a purposeful mistake in the commented code above which we’ll see in the Debugging plugin part of this blog series.
Finally, I’ll Rebuild this code, Update and run the plugin.

Updating the Plugin

Now, let’s say you have updated the code and now you want to re-deploy the plugin code.

Once you have Rebuild. I use Ctrl + Shift + B.
Next, you need to go to the Plugin Registration Tool, select the Plugin Assembly itself and click on Update.
On this screen, even though you see your plugin already selected, click on the three dots to reselect the Assembly and select the .dll file as you originally did while registering it the first time.
And then reselect the assembly and the plugin both and then click on Update Selected Plugins.
Upon correctly updating, the below message is seen and you are done.
Now, let’s run the code and see the “expected” Exception it will throw since we had commented a line on purpose in step #2 in Context of the Plugin section above. 😊

Exceptions

Now, when there are exceptions, you’ll typically see a error pop-up in Dynamics 365 as shown below

Part 4 – Debugging the plugin

Profiling

Now, you’ll need to start Debugging in the Plugin Registration tool

In the Plugin Registration Tool, if a Profiler solution was never installed, you will find this button that says Install Profiler.
It’ll begin installing the Profiler and it takes a few minutes until this is completed.

Once done, you’ll see this message.
One this is done, you’ll see Uninstall Profiler button all the while.
Now, you need to select the Plugin step and then click on Start Profiling.
Once started, the Plugin step will look like this. The step will have “(Profiled)” mentioned.
Now that you have started profiling the plugin step. You’ll need to “perform the operation” in Dynamics 365 CRM. In this case, updating the Group Code field and clicking on Save.
This will not throw the Exception since the method we chose above was Persist to Entity. And the system will just save the record [But of course, the plugin code was not executed since it throws an error]
Next, you can navigate to Plug-in Profiles in Settings
Make sure the Plug-in and custom workflow activity tracking is turned to All in System Settings.

Else, you’ll see this error on navigating to the Plug-in Profiles section in Settings.
Next, you’ll find the record which was captured when we tried to replicate the scenario to capture the issue.
Now, when you open this record, you’ll need to expand the Serialized Profile section and copy all the content into a Notepad file.
For example, I’m naming my file as error.txt. Remember where you stored this file.

Now, let’s Debug the plugin!

Debugging

Now, in order to start debugging the plugin, you’ll need to first, stop the Profiling which we started to capture the logs –

Click on Stop Profiling.
Once stopped, click on the Step, then on Debug to open the Dialog box as shown below.

It’ll open this dialog. Click on the three dots for Profile field.
Select the text file which was saved. It’ll appear if the text file was correctly rendered.
Then, click on the three dots in Assembly Location. This will accept the .dll file of the plugin
Once you select the DLL, it’ll detect the Plugin and it’ll be show as below.
Don’t click on Start Execution yet!! Go to Visual Studio and open Attach to Process.
Shortcut for that is Alt + D [pause for a bit], then press [P].
Find Plugin Registration Tool and then click on Attach.
Once you click on Attach, the VS will be in Debug mode with the Plugin Registration Tool and you can now set the breakpoint at appropriate location in order to capture the debug. Ideally, this should be early on in the plugin to identify the issue step by step.
Now, you can go back to the Plugin Registration Tool and click on Start Execution.
Once it starts, the breakpoint will be hit and you can then take it forward like any C# program debugging using F10, F11, F5 etc.
Let’s assume the exception was hit correctly where we anticipated it to be hit.
You’ll catch the exception and fix the code.
[I had purposely commented in earlier posts for this scenario]
Now, I fix the code. Rebuild and Re-deploy the plugin
And as a result, when I perform the operation again, the plugin works and the child records are updated.
So, I’ll make a change on the Account record.

And if I check the Contact, the same will have been updated there as well. This indicates that our intended functionality was successfully implemented.