CRM - Lookup field name vs relationship field name

Today I thought I'd discuss a little gotcha in CRM 2011 that I'm amazed remained as a "feature" for so long! Have you ever seen "foreign key" fields in a CRM system and noticed that some are called "new_ContactId" where as others are called "new_Contact"? There's a fairly simple reason this occurs, it's basically a result of the developer/consultants preference when creating fields. Let's take a quick look at each method.

Old School - Creating relationships

If, like me, you have progressed from CRM 4 or earlier you generally create relationships between entities using the same method as always existed. You open up the entity customizations, navigate to 1:N or N:1 relationships and you get this screen:

You will notice I have highlighted what it will create the field as in the background: "new_ContactId". Most people comfortable with CRM throughout many versions will be familiar with this convention of creating fields.

New School - Lookups

Since CRM 2011 we now have a second way to create relationships. Rather than going via the relationship links on an entity simply pick the entity where you want the "foreign key" field to reside. In our example this is on the entity called "Custom Method". Navigate to the list of fields and simply add a new lookup field. Like this:

This time you'll notice I have highlighted the field name "new_Contact". We're missing the "Id" part!

Old School or New School?

I guess this is the question, which do you prefer? Personally, I prefer the new field naming convention for one simple reason. As CRM developers you don't really have your head in tables and SQL as much any more. Instead you're using plugins and Entities / Entity References. So generally in a plugin you'll use code like this:

var contactReference = (EntityReference)customMethod["new_ContactId"];

This "Id" always bugged me, because of this simple fact - it's not an Id in code, it's a reference. So if you just wanted the "Id" in code you use this:

var contactId = ((EntityReference)customMethod["new_ContactId"]).Id;

Which I don't like, because you're repeating the abbreviation "Id". In my opinion this kind of violates "DRY" so I will avoid it if at all possible. Using the new school way it looks cleaner without this repetition:

var contactId = ((EntityReference)customMethod["new_Contact"]).Id;

So whenever I create a field using the relationship convention I will manually remove the "Id" part.

What security groups do you belong to within Active Directory?

If you want to see what security groups you belong to within Active Directory open up a command prompt and run the following:

gpresult /V


This is really useful if you are having problems installing a piece of software (such as MS Dynamics CRM) and are hitting weird security problems. Quite often when installing Dynamics CRM you will have asked for and believe you have domain administrator rights, but the installer keeps telling you something like:

Action Microsoft.Crm.Setup.Server.GrantAspNetServiceAccountAccessAction failed. ---> System.Runtime.InteropServices.COMException: The security ID structure is invalid


Running the above command will give you a nice list of exactly what you have:

The user is a part of the following security groups
---------------------------------------------------
    Domain Users
    Everyone
    SophosUser
    BUILTIN\Users
    BUILTIN\Administrators
    Remote Desktop Users
    NT AUTHORITY\INTERACTIVE
    CONSOLE LOGON
    NT AUTHORITY\Authenticated Users
    etc...

Executing stand alone C# code within CRM

A question that I was asked recently, and have pondered for quite some time, is providing an ability to execute some independent/standalone C# code within a CRM instance. There are quite a few ways to do this, but I'll describe my preferred pattern here. The solution I put forward is an attempt to provide complex code solutions that do not require the use of another server or external application. And it should also work both Online and OnPremise.

Firstly, to support our "C#" calls we need a new entity that will trigger it. Let's call it "Custom Method". In it's most basic form it would be a very simple object with just 3 main attributes, the method name, parameters and result:

Next, what we would do is attach a C# plugin on the PreCreate of this that will allow us to run some C# code in the background. Using the developer tools a very basic plugin skeleton that has 1 custom method (contained within the plugin class for simplicity) will look something like this:

public class ExecuteCustomMethod: Plugin
{
    private readonly IDictionary<string, Func<string,string>> methods = 
     new Dictionary<string, Func<string,string>>();

    public ExecuteCustomMethod()
        : base(typeof(ExecuteCustomMethod))
    {
        methods.Add("Add2Numbers", Add2Numbers);
        RegisteredEvents.Add(new Tuple<int, string, string, 
            Action<LocalPluginContext>>
                (20, 
                 "Create", 
                 "xrm_custommethod", 
                 Execute));
    }

    protected void Execute(LocalPluginContext localContext)
    {
        if (localContext == null)
        {
            throw new ArgumentNullException("localContext");
        }
        
        var target = (Entity)localContext
                         .PluginExecutionContext
                         .InputParameters["Target"];

        try
        {
            var name = (string) target["xrm_name"];
            var parameters = (target.Contains("xrm_parameters") ? 
                              (string) target["xrm_parameters"] : 
                              string.Empty);
            target["xrm_result"] = methods[name].Invoke(parameters);
        }
        catch (Exception ex)
        {
            target["xrm_result"] = ex.ToString();
        }
    }

    private string Add2Numbers(string numbers)
    {
        var numberArray = numbers.Split('|');

        return (decimal.Parse(numberArray[0]) + 
                decimal.Parse(numberArray[1])).ToString();
    }
}

You could easily extend the parameters and/or result to use XML and serialize/de-serialize the results to provide a more robust/complete solution. For simplicity purposes I presume the parameter will be provided in a pipe delimited format. Now, you simply execute and retrieve the results as follows:

Effectively this may offer an easy solution to execute some complex stand alone C# for whatever reason required.