I'd like to build off of Luke's post from a while back which explained how to create a simple plugin for CRM 4.0. For those of you who haven't already read his post or seen the simple plugin from the SDK, I highly recommend looking over both to get a real quick but effective rundown of how plugins work. Just like with the examples before, we'll start with a blank C# project in Visual Studio. Some things to consider before coding:
- Make sure any and all custom entities are published.
- Create the references to Microsoft.Crm.Sdk and Microsoft.Crm.SdkTypeProxy.
- Create a Web reference using the url http://localhost:5555/mscrmservices/2007/CrmServiceWsdl.aspx (you can replace localhost:5555 with the appropriate server and port number if different) and give it a name (e.g. CrmServiceRef).
- Sign the project and strong-name it by right-clicking on the project in the Solution Explorer and click Properties (Signing should be the bottom tab when the Properties window appears).
For this example I have created a custom entity called "Vehicle" with an entity name of "new_vehicle" in CRM. I named the web reference "CrmServiceRef" and added it below the other "using" statements as <Project Name>.<Web Ref Name>. With that out of the way we can start coding our plugin:
//Standard references
using System;
using System.Collections.Generic;
using System.Text;
//References added by user
using Microsoft.Crm.Sdk;
using Microsoft.Crm.SdkTypeProxy;
using VehicleNamePlugin.CrmServiceRef;
namespace VehicleNamePlugin
{
public class VehicleNameHandler : IPlugin
{
public void Execute(IPluginExecutionContext context)
{
CrmServiceRef.DynamicEntity vehicle = null; //Check for entity to work with
if (context.InputParameters.Properties.Contains("Target") &&
context.InputParameters.Properties["Target"] is CrmServiceRef.DynamicEntity)
{
vehicle = (CrmServiceRef.DynamicEntity)context.InputParameters.Properties["Target"];
//Check to make sure entity is a Vehicle entity
if (vehicle.Name != CrmServiceRef.EntityName.new_vehicle.ToString()) { return; }
}
else { return; } try
{
//Code to execute
}
catch (System.Web.Services.Protocols.SoapException ex)
{
throw new InvalidPluginExecutionException("An error occurred in the AccountCreateHandler plug-in.", ex);
}
}
}
}
The bolded text points out the key differences between working with standard entities and custom entities in a plugin. Notice that the majority of the code isn’t new (Could be taken straight from Luke’s example), until we get to the declaration of the DynamicEntity. The web reference that we use actually encompasses almost everything within the Microsoft.Crm.Sdk package, so it is necessary to explicitly tack on "CrmServiceRef" to a number of things (e.g. DynamicEntity). If you fail to do so, you will get one or both of the following errors when you try to build:
- '<Object Name>' is an ambiguous reference between 'Microsoft.Crm.Sdk.<Object Name>' and '<Project Name>.<Web Ref Name>.<Object Name>'
- Cannot implicitly convert type 'Microsoft.Crm.Sdk.<Object Name>' to'<Project Name>.<Web Ref Name>.<Object Name>
It is necessary to keep both references, though, since the IPlugin class falls within the Sdk and not the web reference.
One thing to keep in mind: You should regularly update the web reference by right-clicking on it in the Solution Explorer in order to make any changes you’ve made to custom entities visible.Aside from those differences, including a custom entity into a plugin is relatively painless (even though it took quite a while to figure it out in the first place).
