which design paradigm to follow in 2011 for developing plugins and custom applications web applications RRS feed

  • Question

  • Hi

    We are working on migrating CRM 4.0 to 2011, and currently working on converting the 4.0 plugins code to 2011.

    Our 4.0 Plug-In code uses both Microsoft.crm.sdk & Microsoft.crm.sdktypeproxy and Web Services in its coding.

    Which design paragigm of CRM 2011 for developing Plugins and custom applications shouls i go for inorder to upgrade / conver the 4.0 plugin code to 2011.

    Early Bound or Late Bound (please refere http://msdn.microsoft.com/en-us/library/gg327971.aspx for various design paradigms available in CRM 2011 for developing Plugins and custom websites)

    Friday, February 24, 2012 10:00 AM

All replies

  • I would recommend the following

    • Use the Microsoft.Crm.Sdk.Proxy and Microsoft.Xrm.Sdk. This will allow you to use your code in both plugins and custom applications.
    • Use Early bound were you can because this creates cleaner code and allows compile time checking to occur. Using the svcutil (included in the sdk) you can generate the code for early bound (strong typed) entity classes which can be used in combination with the Microsoft assemblies.
      With CRM 2011 the difference between Early and late bound is mostly gone. An early bound class inherits from the late bound entity class allowing you to use both approaches.
      Important to note is that these generated classes must be present in the assembly they are used in, if they are placed in a referenced assembly (such as a library) some of the webservice calls will fail because it is not able to locate the correct type.
    • If you want to run your plugins in the Sandbox (recommended if possible) do not use Linq.

    Patrick Verbeeten

    Friday, February 24, 2012 11:42 AM
  • The main factors are:

    • Within plugins you should use the IOrganizationService instance (which is part of the microsoft.xrm.sdk assembly) that you can get from the IPluginExecutionContext, as this will allow your operations to work within the same transaction as the originating message.
    • Within plugins, any Entity passed via the IPluginExecutionContext (i.e. a an InputParameter or an Image) will be implemented as a late-bound class

    So, for plugins, I'd always use the microsoft.xrm.sdk assembly and late-bound code.

    For other development, the choice is less clear-cut. My preference is to use the same paradigm throughout for server code where possible, so I'd normally also use the microsoft.xrm.sdk assembly and late-bound code. Two areas where this is not possible are if using Silverlight, or if using prior versions of the .Net framework, in which case you have to use the web services

    Microsoft CRM MVP - http://mscrmuk.blogspot.com  http://www.excitation.co.uk

    Friday, February 24, 2012 11:44 AM
  • HI

    Thanks for your reply. 

    1)  We are creating a new plugin in CRM 2011 and want to make use of crmservicehelper.cs helper class. We have used following code snippet to make use of ServerConnection class:

    ServerConnection serverConnect = new ServerConnection();

                            ServerConnection.Configuration serverConfig = serverConnect.GetServerConfiguration();

                            using (_serviceProxy = ServerConnection.GetOrganizationProxy(serverConfig))







    We are facing following exception:

    {System.TypeLoadException: Could not load type 'Microsoft.Xrm.Sdk.Client.IServiceManagement`1' from assembly 'Microsoft.Xrm.Sdk, Version=, Culture=neutral, PublicKeyToken=31bf3856ad364e35'.

       at Wipro.Util.CRM.ServerConnection.GetServerConfiguration()

       at WITRACECRM.Plugins.AutoNumber.AutoNumber.Execute(IServiceProvider serviceProvider)}

    Could you please help us in resolving this.

    Monday, March 5, 2012 6:33 AM
  • When creating a plugin you should create the service proxy differently.

    This is the sample for a plugin from the CRM SDK:

    using System;
    using System.ServiceModel;
    using Microsoft.Xrm.Sdk;
    namespace Microsoft.Crm.Sdk.Samples
        public class SamplePlugin: IPlugin
            public void Execute(IServiceProvider serviceProvider)
                // Obtain the execution context from the service provider.
                IPluginExecutionContext context = 
                // Get a reference to the organization service.
                IOrganizationServiceFactory factory = 
                IOrganizationService service = factory.CreateOrganizationService(context.UserId);
                // Get a reference to the tracing service.
                ITracingService tracingService = (ITracingService)serviceProvider.GetService(typeof(ITracingService));
                    // Plug-in business logic goes below this line.
                    // Invoke organization service methods.
                catch (FaultException<OrganizationServiceFault> ex)
                    // Handle the exception.
    The IOrganizationService is the serviceproxy you can use to connect to CRM. This has the same methods as those avilable on the OrganizationService in you example. The service object returned by the CreateOrganizationService will always be configured to connect to the CRM organization the plugin is registered on.

    Patrick Verbeeten

    Monday, March 5, 2012 12:33 PM
  • Patrick points out that with Plugins, you don't want to create the OrgService that way - but in general, I think the GetServerConfiguration approach isn't all that attractive. Although it's in the context of customizing the ribbon, I have a post here  that discusses doing away with the whole GetServerConfiguraiton and using the CrmConnection and OgranizationService.  Getting rid of the GetServerConfig means you can run the code several different ways and can use configuration (yes, you can technically do it with the GetServerConnection approach but it's clearly not made to work like that. For instance, you'll frequently run into problems with the URLs it uses (especially with CrmOnline) and it goes through a selection of Org instead of one specific one.  You can get it to work generically without manual input, but it's a pain in the neck. If you just make the change referenced in my post - you're done with it.

    But keep in mind as I say that - that the code is only for services, console apps etc. If you're writing a plugin, use the approach Patrick specifies below - that's by far the easiest/best way I know of to get the org service within plugin context.

    Cordially, W.G.Ryan - www.williamgryan.mobi

    Tuesday, March 6, 2012 4:15 PM