Tip #777: So long Microsoft.Xrm.Client and thanks for all the fish

So long and thanks for all the fishAt the beginning of the year we reported some ongoing issues with CrmServiceClient and recommended continuing use of Microsoft.Xrm.Client. The issues reported have been resolved and, as of now, there are no compelling reasons to use Microsoft.Xrm.Client.

If you’re starting new project then the choice is trivial – simply use nuget packages for XrmTooling and you’re all set.

If you have an existing project that utilises Microsoft.Xrm.Client, consider refactoring to replace it with CrmServiceClient. One good reason is that Microsoft.Xrm.Client is no longer distributed as part of SDK and won’t be developed any further. CrmServiceClient, on the other hand, will transition you from SOAP to Web API without any or with very little efforts on your part. And don’t forget support for new features like S2S authenticationCrmServiceClient will support it at some point while you have no chance with Microsoft.Xrm.Client.

7 thoughts on “Tip #777: So long Microsoft.Xrm.Client and thanks for all the fish

  1. Chris Harrington says:

    Is there an updated CrmSvcUtil that can generate early bound classes to use this new client? Are there examples of how to use this in plugins or website code?

    • Hi Chris,

      run your questions by the “source” 🙂

      Is there an updated CrmSvcUtil that can generate early bound classes to use this new client?

      Yes, the existing CRM Svc Util generated classes can be used seamlessly with the Xrm.Tooling.Connector. Also LinQ is supported / service context is supported already.

      Are there examples of how to use this in plugins or website code?

      The examples are the same as before, there are a few minor differences, however its usage is extremely similar.

      HTH
      George

  2. Aron Fischman says:

    Hi,
    Thanks for all the tips. This one in particular was a game-changer for me.
    I am migrating some code for using IOrganizationService to CrmServiceClient. This is pretty straightforward in console apps, etc.

    However, in a custom workflow, I generally use something like this to create a connection to CRM:
    IWorkflowContext context = executionContext.GetExtension();
    IOrganizationServiceFactory serviceFactory = executionContext.GetExtension();
    IOrganizationService service = serviceFactory.CreateOrganizationService(context.UserId);

    Any thoughts on how to create a CrmServiceClient from a workflow (or plugin) context?

    Thanks!
    Aron

    • Hi Aron,

      why would you want to instantiate CrmServiceClient? You already have IOrganizationService that is not going anywhere with web api. If you are after LINQ, you can use CrmOrganizationServiceContext that has a constructor taking IOrganizationService.

      HTH
      George

  3. Jim Liu says:

    George, Dynamics 365 SDK doesn’t have CrmOrganizationServiceContext class.

Leave a Reply

Your email address will not be published. Required fields are marked *