Friday, April 24, 2015

How To Ignore Mismatch Processor Architecture Warnings In Unit Test Assemblies With Faked Assemblies

I was attempting to cleanup the warnings in our solution build and ran into this one:
There was a mismatch between the processor architecture of the project being built "MSIL" and the processor architecture of the reference "Microsoft.TeamFoundation.WorkItemTracking.Client.DataStoreLoader", "x86". This mismatch may cause runtime failures. Please consider changing the targeted processor architecture of your project through the Configuration Manager so as to align the processor architectures between your project and references, or take a dependency on references with a processor architecture that matches the targeted processor architecture of your project. [C:\_Dev\Current Sprint\Xrm.Common.Tests\obj\Debug\Fakes\xrmt\f.csproj]    Xrm.Common.Tests
Researching the error on the web I found that I should be able to use the ResolveAssemblyWarnOrErrorOnTargetArchitectureMismatch Project property to ignore the warning.  I added the property to my Unit Test project and it didn't do anything.  After searching for another 20 minutes I ended up re-reading the warning, and noticed that it was referencing a csproj file other than the one that VS was showing as containing the warning. 
A couple more tests and I finally found that you can include MSBuild properties in the Fakes csproj by using the Compilation Element:
<Fakes xmlns="http://schemas.microsoft.com/fakes/2011/">
  <Assembly Name="Xrm.Common"/>
  <Compilation>
    <Property Name="ResolveAssemblyWarnOrErrorOnTargetArchitectureMismatch">None</Property>
  </Compilation>
</Fakes>

Problem Solved!

Now on to clearing out the rest of the warnings...

Friday, February 20, 2015

How to Import a Solution With a Custom Action and a Plugin Step Registered Against the Custom Action in CRM 2013 SP 1 UR 1

This is a very specific bug that was fixed with CRM 2013 SP1 UR 2.  But if you aren't there yet, here is the issue and the steps to fix it:

Issue:

Attempting to import a Solution with a Plugin Step(s) registered against Custom Action results in the following import error: "sdkmessage with Id = {Guid} Does Not Exist"

Cause:

When CRM 2013 SP1 UR 1 (could be earlier versions as well) imports a Custom Action it is imported as a workflow and the XML in the customizations.xml file looks something like this:

  <Workflows>
    <Workflow WorkflowId="{cf3d243d-e065-4da1-b882-adfecdb6fe9d}" Name="DDLCustomAction">
      <XamlFileName>/Workflows/DDLCustomAction-CF3D243D-E065-4DA1-B882-ADFECDB6FE9D.xaml</XamlFileName>
      <Type>1</Type>
      <Subprocess>0</Subprocess>
      <Category>3</Category>
      <Mode>0</Mode>
      <Scope>4</Scope>
      <OnDemand>1</OnDemand>
      <TriggerOnCreate>0</TriggerOnCreate>
      <TriggerOnDelete>0</TriggerOnDelete>
      <AsyncAutodelete>0</AsyncAutodelete>
      <SyncWorkflowLogOnFailure>1</SyncWorkflowLogOnFailure>
      <StateCode>1</StateCode>
      <StatusCode>2</StatusCode>
      <CreateStage>40</CreateStage>
      <RunAs>1</RunAs>
      <SdkMessageId>{63d9c5b6-74b8-e411-80ef-000d3a100fad}</SdkMessageId>
      <UniqueName>DDLCustomAction</UniqueName>
      <IsTransacted>1</IsTransacted>
      <IntroducedVersion>1.0</IntroducedVersion>
      <IsCustomizable>1</IsCustomizable>
      <PrimaryEntity>none</PrimaryEntity>
    </Workflow>
  </Workflows>


Notice the SdkMessageId and UniqueName.  When this gets imported, CRM only uses the UniqueName, it doesn't use the SDK Message Id, it actually creates a new SDK Message Id.  This is the bug.  If you're just importing a Custom Action, no issues, but when you attempt to import a Plugin Step registered against the Custom Action, the Id's won't match up:

  <SdkMessageProcessingSteps>
    <SdkMessageProcessingStep Name="Xrm.Plugins.Merge: new_DDLCustomAction of  any Entity" SdkMessageProcessingStepId="{0f4fdb54-72b8-e411-9c1a-005056827e6d}">
      <PluginTypeName>Xrm.Plugins.Merge, Xrm.Plugins, Version=1.0.0.0, Culture=neutral, PublicKeyToken=0c1faab69f9562d5</PluginTypeName>
      <AsyncAutoDelete>0</AsyncAutoDelete>
      <InvocationSource>0</InvocationSource>
      <Mode>0</Mode>
      <Rank>1</Rank>
      <SdkMessageId>{63d9c5b6-74b8-e411-80ef-000d3a100fad}</SdkMessageId>
      <EventHandlerTypeCode>4602</EventHandlerTypeCode>
      <Stage>40</Stage>
      <IsCustomizable>1</IsCustomizable>
      <IsHidden>0</IsHidden>
      <SupportedDeployment>0</SupportedDeployment>
      <IntroducedVersion>1.0</IntroducedVersion>
      <SdkMessageProcessingStepImages />
    </SdkMessageProcessingStep>
  </SdkMessageProcessingSteps>


Notice there is no UniqueName, just the SDK Message ID.  This is why the "sdkmessage with Id = {Guid} Does Not Exist" error is getting created. 

Workaround:

There is a workaround if you're unable to upgrade to UR2, update the GUIDs in the solution to match the newly created Id.
  1. Import just the Custom Action Process if it doesn't already exists. This will create the SDK Message Id.
    image


  2. Get the newly created Id.  (There are multiple ways, this is the easiest universal way I could think of) do an advanced Find on Sdk Messages, where the Category Name is "CustomOperation".
    image


  3. Locate the Custom Action that you want, and use the debugger tools (F12) to get the actual html itself for the action.  In it you can find the GUID: 
    <a tabindex="0" title="new_DDLCustomAction" class="ms-crm-List-Link" id="gridBodyTable_primaryField_{8DEDACA9-F32C-4F90-BF6E-A87464C70F72}_1" href="#" target="_self">new_DDLCustomAction</a>

  4. Do a search and replace in the customizations.xml for the current SdkMessageId listed (in my example it would be "63d9c5b6-74b8-e411-80ef-000d3a100fad") and replace all with the newly created Guid ("8DEDACA9-F32C-4F90-BF6E-A87464C70F72").


  5. Rezip your solution.

That's it, your import will work just fine.  The biggest headache is you'll need to do this for each and every org that you import it in, making it a nasty fix if you have multiple environments / org.

Thursday, November 6, 2014

How to Prevent FaultException<TDetail> From Eating Your Stack Trace

Eating 
Any action that is performed by the CRM SDK that results in an exception on the CRM server, is returned as a System.ServiceModel.FaultException<Microsoft.Xrm.Sdk.OrganizationServiceFault> exception.  The interesting problem that this creates, is the FaultException<TDetail> exception class overrides the ToString() method of the Exception class, eating the entire stack trace.  So given the following hypothetical program:
public void Test()
{
    using (var service = GetOrganizationServiceProxy())
    {
        try
        {
            return service.GetEntity<SystemUser>(Guid.NewGuid());
        }
        catch (FaultException<OrganizationServiceFault> ex)
        {
            Log(ex);
            throw ex;
        }
    }
}

The log would only contain the following text:


System.ServiceModel.FaultException`1[Microsoft.Xrm.Sdk.OrganizationServiceFault]: systemuser With Id = f483d6ed-ed8c-4d5d-b6e4-145e8d8ec993 Does Not Exist (Fault Detail is equal to Microsoft.Xrm.Sdk.OrganizationServiceFault).

Which doesn’t contain the stack trace at all. For a simple program like this, it’s pretty easy to figure out where the exception occurred, but in an enterprise level application with hundreds or thousands of sdk calls, it becomes nearly impossible. After looking at the base Microsoft Exception class implementation I came up with the FullStackTraceException class:

/// <summary>
/// Provides a method for handling any exception types that "eat" the stacktrace in it's implementation of ToString()
/// </summary>
[Serializable]
public class FullStackTraceException : Exception
{
    private readonly Exception _exception;

    private FullStackTraceException(Exception ex)
    {
        _exception = ex;
    }

    public static Exception Create(Exception exception)
    {
        return CreateInternal((dynamic)exception);
    }

    private static Exception CreateInternal(Exception exception)
    {
        return exception;
    }

    public static FullStackTraceException Create<TDetail>(FaultException<TDetail> exception)
    {
        return new FullStackTraceException(exception);
    }

    private static FullStackTraceException CreateInternal<TDetail>(FaultException<TDetail> exception)
    {
        return new FullStackTraceException(exception);
    }

    public override String ToString()
    {
        String s = _exception.ToString();

        if (_exception.InnerException != null)
        {
            s = String.Format("{0} ---> {1}{2}   --- End of inner exception stack trace ---{2}", s, _exception.InnerException, Environment.NewLine);
        }

        string stackTrace = _exception.StackTrace;
        if (stackTrace != null)
        {
            s += Environment.NewLine + stackTrace;
        }

        return s;
    }
}



It uses static factories to determine if the exception is of the FaultException<TDetail> type or not.  If it isn’t, the exception is returned unchanged.  If it is, a new version of FullStackTraceException is returned, with an overridden ToString method that includes the stack trace as it would normally appear.  So if the first example was changed to:


public void Test()
{
    using (var service = GetOrganizationServiceProxy())
    {
        try
        {
            return service.GetEntity<SystemUser>(Guid.NewGuid());
        }
        catch (FaultException<OrganizationServiceFault> ex)
        {
            Log(FullStackTraceException.Create(ex));
            throw ex;
        }
    }
}

The ToString() call in Log would return


System.ServiceModel.FaultException`1[Microsoft.Xrm.Sdk.OrganizationServiceFault]: systemuser With Id = f483d6ed-ed8c-4d5d-b6e4-145e8d8ec993 Does Not Exist (Fault Detail is equal to Microsoft.Xrm.Sdk.OrganizationServiceFault).

Server stack trace:
   at System.ServiceModel.Channels.ServiceChannel.HandleReply(ProxyOperationRuntime operation, ProxyRpc& rpc)
   at System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway, ProxyOperationRuntime operation, Object[] ins, Object[] outs, TimeSpan timeout)
   at System.ServiceModel.Channels.ServiceChannelProxy.InvokeService(IMethodCallMessage methodCall, ProxyOperationRuntime operation)
   at System.ServiceModel.Channels.ServiceChannelProxy.Invoke(IMessage message)


Exception rethrown at [0]:
   at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
   at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
   at Microsoft.Xrm.Sdk.IOrganizationService.Retrieve(String entityName, Guid id, ColumnSet columnSet)
   at Microsoft.Xrm.Sdk.Client.OrganizationServiceProxy.RetrieveCore(String entityName, Guid id, ColumnSet columnSet)
   at Microsoft.Xrm.Sdk.Client.OrganizationServiceProxy.Retrieve(String entityName, Guid id, ColumnSet columnSet)
   at DLaB.Utilities.ClientSideOrganizationService.Retrieve(String entityName, Guid id, ColumnSet columnSet) in c:\TFS\DLaB.Utilities\ClientSideOrganizationService.cs:line 88
   at DLaB.Extensions.GetEntity[T](IOrganizationService service, Guid id, ColumnSet columnSet) in c:\TFS\DLaB.Extensions.cs:line 1214
   at DLaB.Extensions.GetEntity[T](IOrganizationService service, Guid id) in c:\TFS\DLaB.Extensions.cs:line 1185
   at DLaB.Example.Test() in c:\TFS\Example.cs:line 7

Which includes the appropriate client side stack trace, allowing for much simpler debugging!  (In actual use, the FullStackTraceException.Create(ex) would occur in the Log method itself to keep the code DRY.)



Enjoy!

Wednesday, August 27, 2014

How To Make It Easier To Create A Plugin For The XrmToolBox

The XrmToolBox is an awesome collection of tools for CRM.  If you haven’t used it before, stop reading this and download it now.  Go ahead.  I’ll wait.

Welcome back…

To date I’ve created 2 plugins for XrmToolBox, Option Set Converter and Early Bound Generator.  While developing them I discovered that there really needed to be a base plugin control to make it simpler to perform CRM calls and perform asynchronous calls.  The base class that I ended up with made development a lot easier for me, and could be very helpful for the rest of the community, so I’m going to highlight it now, the PluginUserControlBase.

UpdateConnection

The first improvement the base makes is simply to implement the required IMsCrmToolsPluginUserControl interface.  The documentation shows UpdateConnection has to check the string name being being passed in to determine which method to call:

public void UpdateConnection(IOrganizationService newService,
                     string actionName = "",
                     object parameter = null)
{
    Service = newService;

    if (actionName == "WhoAmI")
    {
        ProcessWhoAmI();
    }
}


This is a really painful implementation since each method that you need a connection to CRM, will require an if statement for the method to actually call.  It also allows for late bound exceptions if the action name is updated.  Here is my implementation:



public virtual void UpdateConnection(IOrganizationService newService, ConnectionDetail detail, string actionName, object parameter)
{
    Service = newService;
    ConnectionDetail = detail;
    OnConnectionUpdated(new ConnectionUpdatedEventArgs(newService, detail));
    if (actionName == String.Empty)
    {
        return;
    }

    MethodInfo method;
    if (parameter == null)
    {
        method = GetType().GetMethod(actionName);
        if (method == null)
        {
            throw new Exception("Unable to find method " + GetType().Name + "." + actionName);
        }
        method.Invoke(this, null);
    }
    else
    {
        var externalCaller = parameter as ExternalMethodCallerInfo;
        if (externalCaller == null)
        {
            method = GetType().GetMethod(actionName, new[] {parameter.GetType()});
            if (method == null)
            {
                throw new Exception("Unable to find method " + GetType().Name + "." + actionName);
            }
            method.Invoke(this, new[] {parameter});
        }
        else
        {
            externalCaller.ExternalAction();
        }
    }
}


The Service and ConnectionDetail get set, then an Event is raised for any plugins that need to know when the connection is updated.  Then, rather than having an if statement, reflection is used to lookup the correct method to execute.  The ExternalMethodCallerInfo check also allows an action to be used, incase a method needs to be called with more than one parameter.



 



ExecuteMethod



The documentation shows a button clicked event handler having to check if the Service is populated, and then passing in the string name of the method to call:



private void BtnWhoAmIClick(object sender, EventArgs e)
{
    if (Service == null)
    {
        if (OnRequestConnection != null)
        {
            var args = new RequestConnectionEventArgs {ActionName = "WhoAmI", Control = this};
            OnRequestConnection(this, args);
        }
    }
    else
    {
        ProcessWhoAmI();
    }
}


This is also really annoying, having to check each time if the service is populated, and calling it differently depending on it being populated or not.  If the plugin has 3 or 4 actions that require the Crm Service, the OnRequestConnection logic will have to be duplicated multiple times.  I created an ExecuteMethod method to do all of that automagically, using actions rather than strings:



/// <summary>
/// Checks to make sure that the Plugin has an IOrganizationService Connection, before calling the action.
/// </summary>
/// <param name="action"></param>
public void ExecuteMethod(Action action)
{
    if (Service == null)
    {
        var name = action.GetMethodInfo().Name;
        if (name.Contains("__"))
        {
            throw new ArgumentOutOfRangeException("action",
                @"The Action of an Execute Method must not be a lambda.  Use the ExecuteAction(action, parameter) Method.");
        }

        OnRequestConnection(this, new RequestConnectionEventArgs
        {
            ActionName = action.GetMethodInfo().Name,
            Control = this
        });
    }
    else
    {
        action();
    }
}

/// <summary>
/// Checks to make sure that the Plugin has an IOrganizationService Connection, before calling the action.
/// </summary>
/// <param name="action"></param>
/// <param name="parameter"></param>
public void ExecuteMethod<T>(Action<T> action, T parameter)
{
    var caller = parameter as ExternalMethodCallerInfo;
    if (Service == null)
    {
        if (caller == null)
        {
            OnRequestConnection(this, new RequestConnectionEventArgs
            {
                ActionName = action.GetMethodInfo().Name,
                Control = this,
                Parameter = parameter
            });
        }
        else
        {
            OnRequestConnection(this, new RequestConnectionEventArgs
            {
                ActionName = "Recaller",
                Control = this,
                Parameter = parameter
            });
        }
    }
    else if (caller == null)
    {
        action(parameter);
    }
    else
    {
        caller.ExternalAction.Invoke();
    }
}

private void Recaller(ExternalMethodCallerInfo info)
{
    info.ExternalAction.Invoke();
}


WorkAsync



The final improvement that I wanted to highlight was WorkAsync methods which eliminate the need to have duplicated code to create a background worker and update statuses: 



WorkAsync(
    "Message to Display when Starting a CRM Call",
    (w, e) => { /* Work To Do Asynchronously */ },
         e => { /* Cleanup when work has completed */ });


The end result is a much much more simplified plugin:



public partial class SampleTool : PluginUserControlBase
{


    private void BtnWhoAmIClick(object sender, EventArgs e)
    {
        ExecuteMethod(ProcessWhoAmI);
    }

    private void ProcessWhoAmI()
    {
        WorkAsync("Retrieving your user id...",
            (e) => // Work To Do Asynchronously
            {  
                var request = new WhoAmIRequest();
                var response = (WhoAmIResponse) Service.Execute(request);

                e.Result = response.UserId;
            },
            e =>  // Cleanup when work has completed
            {  
                MessageBox.Show(string.Format("You are {0}", (Guid)e.Result));
            }
            );
    }


    private void BtnCloseClick(object sender, EventArgs e)
    {
        base.CloseToolPrompt();
    }
}


Interested in creating a plugin for the XrmToolBox?  Just download the Early Bound Generator and reference the DLab.XrmToolboxCommon dll.



Happy Coding!

Monday, March 17, 2014

How To Interpret AccessRights Numbers In CRM Security Exceptions

When a user attempts to preform an action in CRM there are two potential types of security issues that could arise.
  1. The user’s access level for the privilege required to perform the action is none e.g., attempting to share a contact:
    Contact_No_Share
  2. The user has an access level for the privilege required to perform the action, but it isn’t generous enough e.g., attempting to share a contact with a user outside of the business unit:
    Contact_Org_Share
In either case, if action requires a single privilege, and the user doesn’t have the privilege (or doesn’t have high enough access rights for the privilege), you’ll get an error like the following:
CrmException:
 SecLib::AccessCheckEx failed. Returned hr = -2147187962,
 ObjectID: abe86dd6-d7aa-e311-ade6-cfcd73da4a68,
 OwnerId: db2f6110-1a9d-df11-9d85-005056bb728e, 
 OwnerIdType: 8 and
 CallingUser: edce293b-789d-e311-950c-ed9561bb126a.

 ObjectTypeCode: 4201,
 objectBusinessUnitId: 966fe7c8-89c1-de11-853f-005056bb728e,
 AccessRights: prvShareActivity


This gives combined with the Security Role UI to Privilege Mapping gives all the information required to determine the security rights required.  The Calling user, object, object’s type, object’s owner, object’s owner type, and object’s business, as well as the Access Right required.  Sometimes though, the error looks like this:


CrmException:
 SecLib::AccessCheckEx failed. Returned hr = -2147187962,
 ObjectID: abe86dd6-d7aa-e311-ade6-cfcd73da4a68,
 OwnerId: db2f6110-1a9d-df11-9d85-005056bb728e, 
 OwnerIdType: 8 and
 CallingUser: edce293b-789d-e311-950c-ed9561bb126a.

 ObjectTypeCode: 4201,
 objectBusinessUnitId: 966fe7c8-89c1-de11-853f-005056bb728e,
 AccessRights: 262153


In this case the Access Rights is a little more cryptic.  This is what happens when an operation requires multiple privileges, e.g. Share and Append.  To “decrypt” it you’ll need to know how enum flags work, and what the actual powers of two are in this case.


Below are the values as taken from the Microsoft.Crm.Sdk.Messages.AccessRights Enum

Name Value Binary Value Description
ReadAccess 1 0001 Specifies the right to read the specified type of object.
WriteAccess 2 0010 Specifies the right to update (write to) the specified object.
AppendAccess 4 0100 Specifies the right to append the specified object to another object.
AppendToAccess 16 0001 0000 Specifies the right to append another object to the specified object.
CreateAccess 32 0010 0000 Specifies the right to create an instance of the object type.
DeleteAccess 65536 0001 0000 0000 0000 0000 Specifies the right to delete the specified object.
ShareAccess 262144 0100 0000 0000 0000 0000 Specifies the right to share the specified object.
AssignAccess 524288 1000 0000 0000 0000 0000 Specifies the right to assign the specified object to another security principal.


In the error above, 262153 is

0100 0000 0000 0000 1001

But wait, There is no Access Right with a binary value of 1000.  Since I’ve been unable to find any other documentation, my guess is that something on our installation (that was an upgrade from a CRM 4.0 server) still has a reference to the CRM 4.0 enum values in which AppendToAccess is actually 8 (1000) rather than 16 (0001 0000).


Using that assumption and the table above, 2621534 is made up of ShareAccess, AppendToAccess, and ReadAccess.  This means the user has to have sufficient Access Levels for Share, Append, and Read privileges of the entity, in order to successfully perform the requested operation.

Friday, February 21, 2014

Improved Method To Avoid A System.InvalidOperationException Multi-Threaded Race Condition In CRM 2011

In order to improve performance creating connections to CRM via the C# SDK, we followed the steps outlined here and here, to cache the ServiceManagement and Credentials objects.  After some quick testing, everything ran smoothly and we pushed the changes to prod.  A couple days later, these exceptions started showing up in our logs:
System.InvalidOperationException: Collection was modified; enumeration operation may not execute.
   at System.ThrowHelper.ThrowInvalidOperationException(ExceptionResource resource)
   at System.Collections.Generic.List`1.Enumerator.MoveNextRare()
   at System.Collections.Generic.List`1.Enumerator.MoveNext()
   at Microsoft.Xrm.Sdk.Client.ServiceConfiguration`1.CreateLocalChannelFactory()
A quick Google search turned up this page, which listed the problem being caused by a race condition when creating a connection to CRM, and enabling the proxy types on the OrganizationServiceProxy.  I decided to look into what the SDK was actually doing to create the race condition and this is what I found in the call site where the exception was being thrown:
private ChannelFactory<TService> CreateLocalChannelFactory()
{      
     lock (ServiceConfiguration<TService>._lockObject)
      {
          ServiceEndpoint local_0 = new ServiceEndpoint(this.CurrentServiceEndpoint.Contract, this.CurrentServiceEndpoint.Binding, this.CurrentServiceEndpoint.Address);
          foreach (IEndpointBehavior item_0 in (Collection<IEndpointBehavior>)this.CurrentServiceEndpoint.Behaviors)
              local_0.Behaviors.Add(item_0);
          local_0.IsSystemEndpoint = this.CurrentServiceEndpoint.IsSystemEndpoint;
          local_0.ListenUri = this.CurrentServiceEndpoint.ListenUri;
          local_0.ListenUriMode = this.CurrentServiceEndpoint.ListenUriMode;
          local_0.Name = this.CurrentServiceEndpoint.Name;
          ChannelFactory<TService> local_2 = new ChannelFactory<TService>(local_0);
          if (this.ClaimsEnabledService || this.AuthenticationType == AuthenticationProviderType.LiveId)
              ChannelFactoryOperations.ConfigureChannelFactory<TService>(local_2);
          local_2.Credentials.IssuedToken.CacheIssuedTokens = true;
          return local_2;
      }
}
Even with the Lock statement, the CurrentServiceEndpoind.Behaviors call apparently was still throwing the exception. I then checked the OrganizationServiceProxy to see what EnableProxyTypes() was doing:
public void EnableProxyTypes(Assembly assembly)
{
      ClientExceptionHelper.ThrowIfNull((object) assembly, "assembly");
      ClientExceptionHelper.ThrowIfNull((object) this.ServiceConfiguration, "ServiceConfiguration");
      OrganizationServiceConfiguration serviceConfiguration = this.ServiceConfiguration as OrganizationServiceConfiguration;
      ClientExceptionHelper.ThrowIfNull((object) serviceConfiguration, "orgConfig");
      serviceConfiguration.EnableProxyTypes(assembly);
}
Hmm, nothing there looked to be updating the Behaviors collection. Must be something in the OrganizationServiceConfiguration’s EnableProxyType():
public void EnableProxyTypes(Assembly assembly)
{
      ClientExceptionHelper.ThrowIfNull((object) assembly, "assembly");
      ClientExceptionHelper.ThrowIfNull((object) this.CurrentServiceEndpoint, "CurrentServiceEndpoint");
      lock (this._lockObject)
      {
          ProxyTypesBehavior local_0 = this.CurrentServiceEndpoint.Behaviors.Find<ProxyTypesBehavior>();
          if (local_0 != null)
              ((Collection<IEndpointBehavior>) this.CurrentServiceEndpoint.Behaviors).Remove((IEndpointBehavior) local_0);
          this.CurrentServiceEndpoint.Behaviors.Add((IEndpointBehavior) new ProxyTypesBehavior(assembly));
      }
}
And there it was, the cause of the race condition. One thread calls CreateLocalChannelFactory() while another thread calls EnableProxyTypes(). Even though they are different OrganizationsServiceProxies, they share the same ServiceConfiguration. Even though they are both wrapped in lock statements, they are using different lock objects.

The fix suggested by the only Google result for this error is to add a check to see if the ServiceConfiguration’s CurrentServiceEndpoint has any EndpointBehaviors before enabling the proxy types. This still potentially (although very unlikely) still allows for the exception to occur. I decided to simplify it. Since the only thing the OrganizationServiceProxy does in it’s EnableProxyTypes() is pass the call onto the ServiceConfiguration’s EnableProxyTypes(), and since the ServiceConfiguration is shared amongst all threads, the call to EnableProxyTypes() can be performed directly after the creation of the ServiceConfiguration, before it is returned and used by the OrganizationServiceProxy. This removes the race condition as well as having to check for any existing behaviors before calling EnableProxyTypes(). Below is the utility class that we use to create our OrganizationServiceProxies, sharing the ServiceConfiguration and Credentials.

Before diving into the code, here are some things that aren’t shown below:
  • CrmServiceEntity is a class that contains all of the information required to connect to CRM. It overrides Equals(), so it is a valid Key to use.
  • GetOrAddSafe is an extension method that ensures that only once CrmServiceCreationInfo object gets created per CrmServiceEntity.
And now the code, which is pretty simple. A call comes in to CreateService, with a CrmServiceEntity parameter. GetOrAddSafe is then called, looking for any existing value in the ConcurrentDictionary. If none is found, it calls the constructor for CrmServiceCreationInfo with the CrmServiceEntity parameter. Keep in mind this is locked and will not be called twice for the same CrmServiceEntity.

The ServiceConfiguration and ClientCredential get created as normal, but then if Proxy Types are enabled, the EnableProxyTypes is called on the Service Configuration. There is some reflection magic required to call the method since it is an internal class, as well as a fail safe incase Microsoft ever changes the class name. But the end result is before the ServiceConfiguration object is ever returned, it should have it’s proxy settings set, which means the race condition will never happen. Enjoy!
private static ConcurrentDictionary<CrmServiceEntity, CrmServiceCreationInfo> _crmServiceCreationInfos = new ConcurrentDictionary<CrmServiceEntity, CrmServiceCreationInfo>();
private static readonly object _crmServiceCreationLock = new object();
private static OrganizationServiceProxy CreateService(CrmServiceEntity entity)
{
      var crmServiceCreationInfo = _crmServiceCreationInfos.GetOrAddSafe(_crmServiceCreationLock, entity, e => new CrmServiceCreationInfo(e));
      var orgService = new OrganizationServiceProxy(crmServiceCreationInfo.ServiceConfiguration, crmServiceCreationInfo.ClientCredential);
      if (entity.ImpersonationUserId != Guid.Empty)
      {
          orgService.CallerId = entity.ImpersonationUserId;
      }
      return orgService;
}


private class CrmServiceCreationInfo{
      public IServiceManagement<IOrganizationService> ServiceConfiguration { get; set; }
      public ClientCredentials ClientCredential { get; set; }
      public CrmServiceCreationInfo(CrmServiceEntity entity)
      {
          var orgUri = GetOrganizationServiceUri(entity);
          ServiceConfiguration = ServiceConfigurationFactory.CreateManagement<IOrganizationService>(orgUri);
          ClientCredential = GetCredentials(entity);
          if (entity.EnableProxyTypes)
          {
              // As of at least CRM 2011 Rollup 15 there exists the potential that sharing the Service Configuration and EnablingProxyTypes could cause a 
              // System.InvalidOperationException: Collection was modified; enumeration operation may not execute.
              //    at System.ThrowHelper.ThrowInvalidOperationException(ExceptionResource resource)
              //    at System.Collections.Generic.List`1.Enumerator.MoveNextRare()
              //    at System.Collections.Generic.List`1.Enumerator.MoveNext()
              //    at Microsoft.Xrm.Sdk.Client.ServiceConfiguration`1.CreateLocalChannelFactory()
              // http://social.microsoft.com/Forums/en-US/d8d81294-5c11-4490-824d-649c653c7335/linq-exception-occurs-while-retrieving-paged-crm-data-in-a-multihreaded-manner

              // Rather than not enabling the proxy types if it has already been enabled which could still cause the issue,
              // enable it here which is guaranteed to only execute once.
              // type should be of type OrganizationServiceConfiguration which is an internal type.  If something changes
              // Create a temporary OrganizationServiceProxy to then fix the issue.

              var type = ServiceConfiguration.GetType();
              var method = type.GetMethod("EnableProxyTypes", new[] { typeof(System.Reflection.Assembly) });
              if (method == null)
              {
                  LogManager.GetCurrentClassLogger().Warn("EnableProxyTypes doesn't exist for " + type.FullName);
                  using (var orgService = new OrganizationServiceProxy(ServiceConfiguration, ClientCredential))
                  {
                      orgService.EnableProxyTypes(GetEarlyBoundProxyAssembly());
                  }
              }
              else
              {
                  method.Invoke(ServiceConfiguration, new Object[] { GetEarlyBoundProxyAssembly() });
              }
          }
      }
}

Monday, January 27, 2014

Why Is CRM Displaying A Section That Has Been Defined As Hidden?

After being head down in CRM for the last 2 years, there are few things that surprise me, but the situation I’m about to describe, threw me for a loop:Huh

Our client had an entity with multiple forms.  All the forms looked virtually identical with the 40 same basic fields, split up among 5 different sections.  4 of the sections were defined as visible, but one wasn’t.  It contained the name of the entity (which was programmatically calculated from various fields, which explains why it was on the form but hidden) along with a couple other fields that were required by the JavaScript of the form, in order to process the business rules of the entity, but the actual business user wouldn’t care about.

Everything had been working fine until we upgraded the on-premise version of CRM from rollup 11 to rollup 15.  After the rollup, we found a bug where on one of the forms, for a particular subset of data, the hidden section was mysteriously being displayed.  I tried everything I could think of, defaulting the section to being hidden, setting it to being hidden as the last function call of the onLoad JavaScript, even setting all of the fields within the hidden section as being hidden.  All to no avail. 

Finally, in a desperate attempt to determine why the section was being displayed, I searched for “setVisible” in the JavaScript of the page, and placed a break point everywhere in the source code.  20 breakpoints later one of the breakpoints was triggered and I finally had a call stack to point me to the problem.  Although it was all minified JavaScript, chopped full of 3 character variables and functions containing only a ‘$’ a letter and a number, one of the function’s names was in English and caught my eye, “setFocus”.  Why was Microsoft setting the focus on a random field on my custom form?  A few debugging steps later, and I had my answer:

CRM has JavaScript that runs after the onLoad function of the form to find the first field on the form that is not read-only, and then sets the focus on that field.  As a part of the setFocus function, it ensures the field is visible by not only setting the field as visible, but setting it’s parent section as visible as well.  So what was happening on this one particular form was all of the fields on the form before the hidden section had been marked as read-only, and when Microsoft’s JavaScript searched for the first field that was not read-only, it found the name field in the hidden section, set the focus on it, which made the section visible.

The solution was relatively simple, make all the fields in the section read-only, and update any JavaScript that updated them to always force submit.  Making the fields read-only removed them from being valid focusable candidates, and adding force submit to each field ensured that any updates the JavaScript made would still get posted back and updated in CRM.  Problem Solved.

Debugging Microsoft’s minified JavaScript is never fun or easy, but sometimes it’s a necessity.  Happy debugging!