Plugins are custom classes that implement the IPlugin interface. The class can be written in any .NET framework-compliant language such as Microsoft Visual C# or Microsoft Visual Basic .NET. The following screenshots illustrate how users can create a plugin project.

1. Firstly, the user can create a new class library project:

2. After the project is created, the user can add a new Class... item to the project. The new class would act as the plugin class:

3. Here's how we can add a new class file to the solution:

4. All the plugin projects must have a reference for the Microsoft.Xrm.Sdk and Microsoft.Crm.Sdk.Proxy assemblies.

If a person is writing a plugin for the first time, they must download the appropriate Dynamics SDK matching the target environment. You can refer to this MSDN link for downloading the SDK:
https://www.microsoft.com/en-us/download/details.aspx?id=50032

5. Here's how we can add assembly references:

6. Here's how we can add the required assembly references:

7. Browse or select the required references, in this case, Microsoft.Xrm.Sdk.dll:

8. Add the Microsoft.Xrm.Sdk.dll reference:

9. The next step would be to add the respective using statements in the plugin class. Also, any plugin must implement the IPlugin interface:

      using System; 
      using System.Collections.Generic; 
      using System.Linq; 
      using System.Text; 
      using Microsoft.Xrm.Sdk; 
      using Microsoft.Crm.Sdk.Messages; 
      using Microsoft.Xrm.Sdk.Query; 
 
      namespace SamplePluginProject 
      { 
        public class PreCreateUpdateAccountSamplePlugin : IPlugin 
        { 
          public void Execute(IServiceProvider serviceProvider) 
          { 
          } 
        } 
      } 

10. When we implement the IPlugin interface, we must also define the  Execute method. This method would be the starting point when control would be transferred to the plugin class.
11. After adding the method, build the project to ensure that everything is correct.
12. After the project builds successfully, to deploy the assembly in Dynamics CRM, we must sign the assembly. We can do this by navigating to the properties of the project:

13. Set the assembly name for the project:

14. Sign the assembly:

15. After the plugin assembly has been generated successfully, the next step is to deploy the plugin assembly in Dynamics CRM. All plugin deployments take place using a standard tool, Plugin Registration Tool, provided by Microsoft in the SDK. It just requires the .NET framework to be installed on the system from which the user is planning to deploy the plugins. As a first step, the user will need to navigate to the file explorer directory where the plugin registration tool has been downloaded:

16. The user then needs to click on PluginRegistration.exe:

17. The user should then click on the Create New Connection button. On doing so, a popup window for entering the user credentials should open up:

Please note that the user must enter the credentials for a user with the System Customizer role. Otherwise, the user will not be allowed to register the assembly.

The user should next click on the Login button. If the credentials are correct, the user should be redirected to the next screen, wherein he/she will be able to see all the plugins and custom workflow assemblies that have been registered in the Dynamics CRM organization:

18. After this, the user can now register the plugin assembly created in the previous step. As illustrated in the following screenshot, the user can firstly click on the Register button, which should open a dropdown wherein the user can click on Register New Assembly:

On doing so, a window popup screen should load. The user can now navigate to the plugin assembly created in the preceding steps:

Register the plugin assembly into the CRM:

Once the user clicks on the Open button, review that the assembly should get loaded. Also, all the classes that implement the IPlugin interface should also appear on the screen:

Note that, as explained earlier, the isolation mode for online deployment can only be sandbox. For on-premise, depending upon the required functionality in the plugin, we can either choose sandbox or none.

When we register a plugin assembly, Dynamics CRM needs to store it somewhere so that it can be loaded whenever the associated event gets triggered. There are three options for the same:

• Database: The assembly is stored in the Dynamics CRM DB. All assemblies wherein the isolation mode is sandbox will always be stored in the database. One major advantage of using the database approach is that the assembly is automatically distributed across multiple CRM servers in a data center cluster. However, in case we are referencing some external assemblies, then we will need to firstly merge the assemblies using some external tool such as ILMerge.
• Disk: If the user selects this option, the assembly will be copied in the CRM bin folder. This option is only available for Dynamics CRM on-premise, where we do have access to the CRM bin folder.
• GAC: As in the case of disk deployment, the option is only available for Dynamics CRM on-premise. When we use this deployment, the assemblies are copied to the GAC.

With this, we have defined the outer structure of the plugin project. The next step would be to write the plugin class, which would govern all the event handlers.

1. After all the steps are done, the user can click on the Register Assembly button. If everything is fine, the user should receive a success message:

2. Once the user clicks on the OK button, he/she should again be navigated to the main page, where he/she will see the list of registered assemblies. Review that the newly registered assembly should also be there: