Creating a customized Plug-in Template for Microsoft Dynamics CRM 4.0
Today we welcome MVP Bill Ryan from CustomerEffective as our guest blogger.
In its basic form, CRM 4.0 Plugin development is straightforward, however it has many monotonous elements. This walkthrough on writing Plugins illustrates many of the repetitive tasks that plugin development entails. Among them are:
- Creation of a new Class Library Project
- Renaming of the default class (class1.cs or class1.vb to Plugin name)
- Adding references to the Microsoft.Crm.Sdk & Microsoft.Crm.SdkTypeProxy libraries
- Aliasing those libraries
- Making the class inherit from the IPlugin interface
- Adding the methods for that interface (or letting VS do it for you)
Most of these items are pretty simple to do, but it is monotonous and you have to remember to do it each time. However most non-trivial plugins require some sort of configuration information. Because plugins are dynamic link libraries hosted by CRM (and typically stored in the database), you can't use Settings.config,app.config or web.config files like you would in most other projects. If you need this functionality, you need to roll your own solution.
Fortunately, when you register each step for your Plugin, the PluginRegistration tool gives you two sections, one for an unsecured configuration and one for Secure Configuration. But unless you write code to do something with this information, simply storing it will provide no benefit. (Mitch Milam has an excellent introduction to this). To take advantage of configuration information, you need to add a new constructor to your plugin and then write code to read the settings.
You can just copy and paste his code if you'd like, but in all likelihood you'll probably want to write something specifically suited to your needs. Normally this would be something you'd just create in a library and attach as a reference to your project. However because of the plugin registration process, you'll typically want to work with as few dll's as possible (assemblies which reside in the Global Assembly Cache are an exception to this because you don't need to do anything special to use them).
Anyway, I found myself copying and pasting the same class over and over into each plugin I wrote and it was something that got old quickly. Additionally, when ever developers come on board who aren't familiar with Plugin development, they will typically get stuck making the same mistakes you made when you first started writing plugins, something which can cost a lot of time and frustration.
Read more for Bill's solution... Cheers,
MVP Bill Ryan
