Sunday, March 20, 2011

Filtering generated entities with CrmSvcUtil

In CRM 2011 you can create early-bound entity classes using the code generation utility (CrmSvcUtil.exe) that comes with the SDK.  This gives you nice strongly-typed entity classes that you can use with full intellisense in Visual Studio and in linq queries (and many other benefits).

However, the cs file generated from this utility can be over 5 - 10MB in size, which is a lot when you want to include it in a CRM plug-in where you should try to keep your assembly as small as possible.

By default the utility will generate classes for every entity in the CRM organization, but fortunately Microsoft has provided a way to filter which entities are generated.

To filter the entities that are generate, we need to create an extension for the CrmSvcUtil utility. Basically, we have to create a small class library that implements an interface used by the utility. The SDK provides a little bit of info, but not much in the way of examples.  So here's what we need to do:
  1. Create a new C# class library project in Visual Studio called SvcUtilFilter.

  2. In the project, add references to the following:
    1. CrmSvcUtil.exe   This exe has the interface we will implement.
    2. Microsoft.Xrm.Sdk.dll  (found in the CRM SDK).
    3. System.Runtime.Serialization.

  3.   Add the following class to the project:

using System;
using System.Collections.Generic;
using System.Xml.Linq;
using Microsoft.Crm.Services.Utility;
using Microsoft.Xrm.Sdk.Metadata;

namespace SvcUtilFilter
{
    /// <summary>
    /// CodeWriterFilter for CrmSvcUtil that reads list of entities from an xml file to
    /// determine whether or not the entity class should be generated.
    /// </summary>
    public class CodeWriterFilter : ICodeWriterFilterService
    {
        //list of entity names to generate classes for.
        private HashSet<string> _validEntities = new HashSet<string>();
       
        //reference to the default service.
        private ICodeWriterFilterService _defaultService = null;

        /// <summary>
        /// constructor
        /// </summary>
        /// <param name="defaultService">default implementation</param>
        public CodeWriterFilter( ICodeWriterFilterService defaultService )
        {
            this._defaultService = defaultService;
            LoadFilterData();
        }

        /// <summary>
        /// loads the entity filter data from the filter.xml file
        /// </summary>
        private void LoadFilterData()
        {
            XElement xml = XElement.Load("filter.xml");
            XElement entitiesElement = xml.Element("entities");
            foreach (XElement entityElement in entitiesElement.Elements("entity"))
            {
                _validEntities.Add(entityElement.Value.ToLowerInvariant());
            }
        }

        /// <summary>
        /// /Use filter entity list to determine if the entity class should be generated.
        /// </summary>
        public bool GenerateEntity(EntityMetadata entityMetadata, IServiceProvider services)
        {
            return (_validEntities.Contains(entityMetadata.LogicalName.ToLowerInvariant()));
        }

        //All other methods just use default implementation:

        public bool GenerateAttribute(AttributeMetadata attributeMetadata, IServiceProvider services)
        {
            return _defaultService.GenerateAttribute(attributeMetadata, services);
        }

        public bool GenerateOption(OptionMetadata optionMetadata, IServiceProvider services)
        {
            return _defaultService.GenerateOption(optionMetadata, services);
        }

        public bool GenerateOptionSet(OptionSetMetadataBase optionSetMetadata, IServiceProvider services)
        {
            return _defaultService.GenerateOptionSet(optionSetMetadata, services);
        }

        public bool GenerateRelationship(RelationshipMetadataBase relationshipMetadata, EntityMetadata otherEntityMetadata, IServiceProvider services)
        {
            return _defaultService.GenerateRelationship(relationshipMetadata, otherEntityMetadata, services);
        }

        public bool GenerateServiceContext(IServiceProvider services)
        {
            return _defaultService.GenerateServiceContext(services);
        }
    }
}

    This class implements the ICodeWriterFilterService interface.  This interface is used by the class generation utility to determine which entities, attrributes, etc. should actually be generated.  The interface is very simple and just has seven methods that are passed metadata info and return a boolean indicating whether or not the metadata should be included in the generated code file.  

    For now I just want to be able to determine which entities are generated, so in the constructor I read from an XML file (filter.xml) that holds the list of entities to generate and put the list in a Hashset.  The format of the xml is this:

    <filter>
      <entities>
        <entity>systemuser</entity>
        <entity>team</entity>
        <entity>role</entity>
        <entity>businessunit</entity>
      </entities>
    </filter>

    Take a look at the methods in the class. In the GenerateEntity method, we can simply check the EntityMetadata parameter against our list of valid entities and return true if it's an entity that we want to generate.

    For all of the other methods we want to just do whatever the default implementation of the utility is.  Notice how the constructor of the class accepts a defaultService parameter.  We can just save a reference to this default service and use it whenever we want to stick with the default behavior.  All of the other methods in the class just call the default service.

    To use our extension when running the utility, we just have to make sure the compiled DLL and the filter.xml file are in the same folder as CrmSvcUtil.exe, and set the /codewriterfilter command-line argument when running the utility (as described in the SDK):

    crmsvcutil.exe /url:http://<server>/<org>/XrmServices/2011/Organization.svc /out:sdk.cs  /namespace:<namespace> /codewriterfilter:SvcUtilFilter.CodeWriterFilter,SvcUtilFilter

    That's it! You now have a generated sdk.cs file that is only a few hundred kilobytes instead of 5MB.

    One final note:  There is actually a lot more you can do with extensions to the code generation utility.  For example: if you return true in the GenerateOptionSet method, it will actually generated Enums for each CRM picklist (which it doesn't normally do by default).

    Also, the source code for this SvcUtilFilter example can be found here.  Use at your own risk, no warranties, etc. etc.

    -Erik Pool

    Tuesday, March 1, 2011

    Debugging Silverlight web-resources that connect to CRM Online.

    Debugging Silverlight web-resources in CRM 2011 can be pretty tedious when you have to constantly re-upload your XAP file to the CRM server and then manually attach the debugger to the IE process. If you run the Silverlight application from your own development machine (using the ASP.NET Development server) you can quickly start debugging by hitting F5 in Visual Studio, but the app won't be able to make any requests to the CRM server because of Silverlight's cross-domain restrictions.

    If you have an on-premise CRM server you can get around the cross-domain restrictions by putting a ClientAccessPolicy.xml file in the root of the CRM web application (See Markus Konrad's post on creating the policy file), but CRM online won't let you upload a ClientAccessPolicy, so you have to be a little more clever.  One method is to just create a proxy to pass all the requests to the CRM server.

    Creating a proxy for CRM SOAP requests
    A quick note: This works for the SOAP Organization service and the example at the end of this post only uses the SOAP service. I'm not sure if a similar proxy would work for the REST endpoint  (Given the REST endpoint's limitation I rarely use it anyway).

    To get web-service requests to go from a Silverlight application w just need a few things:
    1. Create an aspx page in the web project that's hosting the Silverlight app that will act as our proxy.
    2. Program the proxy page to forward all posted requests to the CRM Online web-service endpoint.
    3. Authenticate against CRM Online and attach the LiveId security token to each request.
    4. Configure the Silverlight app to point to the proxy page.


    Steps 1 and 2 are actually pretty straightforward once you pull out fiddler and figure out what the soap requests work like. Step 3 is the complicated bit but the sample code in the CRM SDK provides an example of authenticating against CRM Online (see sdk\samplecode\cs\wsdlbasedproxies\online). Once you've authenticated and have the security token you can just inject the token right into the header of the SOAP request.

    I've built an example application which you can download here.  It's just a simple Silverlight application that makes create, retrieve, update, delete, and execute request to CRM Online using the proxy described above.





















    To try it out just update the constants defined at the top of Proxy.aspx.cs:
    //Update these constants to match your CRM Online account
    const string host = "orgName.api.crm.dynamics.com";
    const string userName = "erik.pool@example.com";
    const string password = "Password";

    Also note the GetOrganizationService method in the Silverlight app. If the current page is running on "localhost" it assumes you're debugging and points the org service url at the proxy.aspx page.  This way the same silverlight app works on my dev machine and when it's deployed to CRM Online.

    if (href.Contains("localhost"))
    {
       Uri baseUrl = new Uri(href, UriKind.Absolute);
       orgServiceUrl = new Uri(baseUrl, "SoapProxy/Proxy.aspx");
    }
    else
    {
       orgServiceUrl = new Uri(location.GetProperty("protocol") + "//" + location.GetProperty("host") + "/xrmservices/2011/organization.svc/web");
    }

    Download the source code here.

    -Erik