Today I’m kicking off the posts on plugins. I dedicate today’s post to CRM developers who are planning for plugin development. I have collected and provided all the information that you would need to understand before you start architecting your plugin.
Before we get started, please check the prerequisites that you should be aware of:
- CRM SDK 2011
- Microsoft Visual Studio 2010 or higher
Plug-ins are normal classes which are built using Class library project. They implement the IPlugin interface. All cases exposed in CRM 2011 are .NET Framework 4 CLR-compliant. You will need to add Microsoft.Xrm.Sdk.dll and Microsoft.Crm.Sdk.Proxy.dll assembly references to your project in order to compile plug-in code. All these assemblies can be found in the SDKBin folder of the SDK download. Refer to http://msdn.microsoft.com/en-us/library/gg594416 to see the sample code for plugin.
Designing a plugin When you start thinking about the plugin make sure you have gone through the Event Execution pipeline described here http://msdn.microsoft.com/en-us/library/gg327941
Handling Exceptions Here’s is the sample to catch your exceptions: http://msdn.microsoft.com/en-us/library/gg327884. This sample contains the code applicable for Console Application. You can choose to write this into a file on a server. This is a business logic to be decided on the fly.
Developing CRM Online Plugins vs. CRM OnPremise Plugins When you start working on CRM online you might want to take care of not using IOrganizationService directly like you would do in custom SDK applications. You will land-up in Security Exception, the reason being sandboxed environment. Microsoft on cloud restricts the environment with unauthorized usage.
The sandbox environment is limited to access Registry settings, event logs etc. This is due to partial trust on assemblies. You might want to go through the definition of Sandbox environment http://en.wikipedia.org/wiki/Sandbox_%28computer_security%29.
For more details on CRM Plugin Trusts, please read http://msdn.microsoft.com/en-us/library/gg334752
Coming back to CRM OnPremise, You can allow your sandbox environments to make only web requests. This ideally means when you explicitly write connection to access CRM Web requests it will allow that. For this you will need to make registry changes.
Registry Key: HKEY_LOCAL_MACHINESOFTWAREMicrosoftMSCRMSandboxWorkerOutboundUriPattern
Value:
^http[s]?://(?!((localhost[:/])|([.*])|([0-9]+[:/])|(0x[0-9a-f]+[:/])|(((([0-9]+)|(0x[0-9A-F]+)).){3}(([0-9]+)|(0x[0-9A-F]+))[:/]))).+
Extract from: http://msdn.microsoft.com/en-us/library/gg334752 Here’s the sample for Web Access in plugin: http://msdn.microsoft.com/en-us/library/gg509030
Debugging the plugin When debugging an OnPremise plugin, please make sure you’ve read http://msdn.microsoft.com/en-us/library/gg328574.aspx to check the name of processes which would be required to attach at the time of debug.
When debugging CRM Online Plugin you can make use of Plugin Profiler which is a part of Plugin registration tool. Here are the steps http://msdn.microsoft.com/en-us/library/hh372952.aspx
Registering Plugin Please check out a walkthrough available at MSDN: http://msdn.microsoft.com/en-us/library/gg309580
Custom SDK application vs. Plug-ins When you start writing SDK application the first step that you would start with is with writing IOrganizationService to execute the functions like Create, delete and execute etc..,. When you start writing a plugin the service is already made available to you within in the context of it. Here’s is the implementation /or sample of it http://msdn.microsoft.com/en-us/library/gg309673.aspx#bkmk_access.
Other topics that might interest you
Cheers,
Apurv