At 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 authentication – CrmServiceClient will support it at some point while you have no chance with Microsoft.Xrm.Client.

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?

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.