Tuesday, January 29, 2008 - Posts

Writing & Deploying a CRM 4.0 Plug-in
by Luke Simpson 01.29.08

2 Comment(s)

Like most developers, I am often the most frustrated by generic error message that never seem to give me enough information to solve the problem at hand.  Because of this, and an funny situation that I went through while trying to publish a Plug-in with CRM 4.0, I thought that it might be nice to have a complete walkthrough of a simple Plug-in, from development to deployment.  I have seen several blogs focusing on the code involved in writing a Plug-in, but not many on the deployment side, and this seems to be where the most issues occur.The following code is about as simple as a Plug-in gets.  It runs on the PreCreate event of an Account (renamed Company in this installation), and generates an Account Number (int) for the Account in question.  This sample is nearly identical to one included in the SDK.

using System;
using System.Collections.Generic;
using System.Text;
using Microsoft.Crm.Sdk;
using Microsoft.Crm.SdkTypeProxy;

namespace IS
{
      public class AccountPreCreate: IPlugin
      {
            public void Execute(IPluginExecutionContext context)
            {
                  // Verify we have an entity to work with
                  if (context.InputParameters.Properties.Contains("Target") && context.InputParameters.Properties["Target"] is DynamicEntity)
                  {
                        // Obtain the target business entity from the input parmameters.
                        DynamicEntity entity = (DynamicEntity)context.InputParameters.Properties["Target"];
                        // Verify that the entity represents an account.
                        if (entity.Name == EntityName.account.ToString())
                       {
                              // Generate a new Account Number
                              Random rndgen = new Random();
                              StringProperty accountNumber = new StringProperty("accountnumber", rndgen.Next().ToString());
                              entity.Properties.Add(accountNumber);
                        }
                  }
            }
      }
}

Very simple.  The only thing to remember is to include references to Microsoft.Crm.Sdk and Microsoft.Crm.Sdk.SdkTypeProxy in your project.  These dll's are found in the bin folder, wherever you extracted the SDK to. Now that we have written our simple plugin, and verified that it builds without errors, we are ready to deploy using Microsoft's handy little tool, right?  Wrong!  This is where I had my problems, and they were a little embarrasing.  New to CRM 4.0, all plug-in assemblies MUST be signed.  This is a little security measure that Microsoft added.  Signing code is really quite simple, but .Net developers seem to be divided into two camps.  Those that sign everything, and those that have never signed an assembly in their lives.  Unfortunately, if you do not sign your assembly it will register without errors but it will return a very generic error stating that the Plug-In was unable to be loaded.  Because of this, the next section is for the latter group of developers who have never deemed it necessary to sign an assembly.  In order to do this, all you need to do is right-click on your project, and select Properties.

After the Properties screen appears, select the Signing* tab, and in the dropdownbox select <New...>.  Then a prompt will appear asking for a Key file name, and for a password.  It is your option to password protect the key, if you do not want to, simply uncheck the box.  Otherwise, add a password of your choice.

 

 

 

 

 

 

 

 

 

 

Then save, and close the Properties window.  You will now have a new file in your project.  If you chose not to password protect it, the file will end in '.snk', otherwise it will end in '.pfx'.Now you are ready to publish the Plug-in.  If you haven't already, build and deploy the Workflow Configuration tool that ships with the SDK.  There are instructions on how to deploy this VS 2005 addin.To deploy your Plug-in, build the Project and copy the dll to the assembly folder in CRM, by default this is located at C:\Program Files\Microsoft Dynamics CRM\Server\bin\assembly. Then, while in Visual Studio 2005, select Tools --> CRM Plug-in Registration Tool.  A screen will appear asking for connection credentials to your CRM installation.  Enter them in, and click 'Get Connection':

Click the 'Assembly Registration' button.  Here you will register the Assembly for CRM.  Select the dll you copied into the CRM assembly folder earlier.  Then select the Class that you wish to use in that dll.  To the right, you will see an option to register to the Database or to Disk.  For debugging purposes, I think that registering to Disk is best, while I like a Database registration for final deployment.  After you have selected these options, select 'Register' on the right.  A message will appear confirming the registry.  You can also select 'Get Assemblies' to show all assemblies that have been registered to this CRM installation.

Close the window, and select 'Step Registration' from the main window.  From this new screen, you will tell CRM when to execute each method.  Select your Assembly and PluginType from the drop downs.  Then configure your options.  For our purposes today, we want the Plug-in to work in Synchronous mode, Stage Pre, and Deployed only to the Server.  The MessageName is 'Create' and the EntityName to work on is 'account'.  Only out of the box entities appear in this list, but custom entities can be used by typing the schema name in the text box.  After this is complete, click 'Register step on PluginType'.  And you are done! 

 

Close all of the CRM Plugin Registration Tool windows, and launch CRM to see how it works.

 

 

Filed under: Technical Tips

Hiding System Views in CRM 4.0
by Jeremy Hofmann 01.29.08

3 Comment(s)

This post describes a customization to CRM 4.0 which is not a supported by Microsoft, Crowe or me but something I needed to find a solution to given a client request.  Please take this into account before attempting to make this change as in most situations you never want to update the CRM database tables directly.  This may cause problems with upgrades and future releases.  However, there are times when your users will demand a system change and you may be forced to take a bit of technical leap to make them happy.

 

Hiding system views in CRM 4.0 is one such area.  For example, your implementation may not use the Marketing Campaign entities, and you wish to hide the “Contacts: No Campaign Activities in Last 3 Months” system view.

 

While there isn’t a clean way to do this currently using the standard configuration UI, you can force a system view to become a private view through a bit of direct database magic:

 

1.       Navigate to the system view.

2.       Make a change to the view, such as switching the column order.  This will create a new record in the SavedQuery base table with the CustomizationLevel = 1.  Customization = 0 records should never be touched since these are shared across mult-tenant organizations.

3.       Publish the entity.

4.       Find the view in the SavedQueryBase table.  There may be several entries, so use the view with the CustomizationLevel equal to 1 that was created earlier.

5.       Update the record and set the IsPrivate flag to 1.

 

 

UPDATE SavedQueryBase
SET IsPrivate = 1
WHERE [Name] = 'Contacts: No Campaign Activities in Last 3 Months'
AND CustomizationLevel = 1

 

 

Now once you navigate back to the entity, the view will no longer appear in the list.

 

Again, use the above SQL trick with caution.  Manipulating the CRM database is not encouraged.  However, since the functionality to hide system views existed in CRM 3.0, we felt this is something clients may have an interest in pursuing in order to meet the needs of their existing users.

 

Filed under: Technical Tips