Step-By-Step develop a Plug-in with CRUD functionality

by Carmel Schvartzman

1. In this walkthrough we will learn How-to  develop a custom plug-in .  Custom plug-ins extend the CRM events functionality, by running custom code both before or after an event performs its operations. Plug-ins are more powerful than custom workflows, because they are not bound by logic patterns and features that the workflow editor supports, and the whole code is written in C#. Also plug-ins allow you to debug the entire code.
2. Create a new  project in Microsoft Visual Studio of "CLASS LIBRARY" type:
3. Add to the project the following references (CRM references are from the SDK\bin folder):
   1. If you do not have the Microsoft.IdentityModel.dll installed on your computer, you can download it from  Windows Identity Foundation.
4. Add the necessary USINGS to your code:
5.  Because the target framework default option for a new project is "CLIENT PROFILE", go to PROPERTIES and under "APPLICATION" and change the target framework to ".NET Framework 4":
6. Now we need to sign the assembly  using the "signing" tab of the project's  properties:
7. Our plug-in will implement the IPLUGIN interface, so add the code:
8. Now we'll write our custom plug-in. First of all, we'll need a CONTEXT that allows us to communicate with the CRM webservices. We'll be using the LATE-BINDING approach, that means our code won't know the properties of the object ; instead we'll use the "Attributes" collection of the class "Entity": there we'll have to use the exact names of the entity properties. We won't have compile-time checking , so be careful and usa the logic names, not the shema names. Therefore we'll need the CRM's  IOrganizationService, an interface that provides programmatic access to the metadata and data for our CRM Organization. In order to do that, we'll use the IOrganizationServiceFactory,  as stated at the MSDN documentation:  we'll create it using the  GetService<......>() method of the context. So write the following code:and next:
9. Now we have got the OrganizationService, so let's check for the existence of the object passed from the CRM to our plug-in. This entity can be reach inside the "Target" input parameter. Let's suppose our plug-in was called on an entity of "Contact" type:
   
   After we have got the primary entity, we can perform CRUD operations on it.
10. Create a new method, called AddNewAccount:
    
    
    The method will get the Crm Service and the Entity we just got from the input parameter. Next we create a new entity of "Account" type.
11. We update the attributes of the new entity, using the LATE-BINDING approach: 
12. Finally, we use the webservice Create() method to save the new entity instance, and call the AddNewAccount() method: 
13. The next stage is to deploy the DLL plug-in to the Crm server. We need the Plugin Registration Tool that comes with the CRM 2011 SDK, therefore copy that GUI to some directory at the CRM server:
14. Double click the PluginRegistration tool:
15. Now, press CONNECT to discover your CRM webservice:
    
16. If your CRM server hosts more than one Organization, select the one to wich you developed your plug-in. Check that the selected CRMService URL is the one you want to deploy your plug-in. Now press "REGISTER" and next "REGISTER NEW ASSEMBLY":
17. Now select the assembly you want to deploy:

It's strongly recommended that you set up the ISOLATION MODE to "SANDBOX": the SANDBOX feature gets code executed in an isolated and trusted environment. In the case your plug-in consumes too much server resources, SANDBOX mode will remove it from the event pipeline where you registered  your code. Also, the same will be done in case of continuous failing.

IMPORTANT: the assembly can be stored in the DISK or in the DATABASE. At the development stage, it's recommended you store it at the DISK, because there you can also copy the .PDB file used for debugging purposes. Later, when you finished testing your code, YOU MUST DEPLOY IT TO THE DATABASE!! Why? Some reasons are:

• The assemblies registered on database can be included in a solution hosted in sandbox or in CRM ONLINE.
• If your CRM server is load balancing, storing the DLLs in DATABASE will allow CRM to automize the process of updating and deploying changes.
•  There's no need to restart the CRM servicesmaking IISRESET on the applicationpool because the update of an assembly will take effect automatically after you press the UPDATE button.So instead of selecting "DATABASE" select the option "DISK" for now.

 That's all

Happy programming    :-)

כרמל שוורצמן