Replacement for Microsoft.Xrm.Client for CrmSvcUtil

(0) Share

Report

Posted on by Community Member

Hi,

We are currently in the process of upgrading from CRM 2011 to Dynamics 365.

So far, we removed static references to Microsoft.Xrm.Sdk and replaced them with references to the Microsoft.CrmSdk.CoreAssemblies NuGet package. We also removed references to Microsoft.Xrm.Client to replace them with references to Microsoft.Xrm.Tooling, including changing our uses of the OrganizationService class with the CrmServiceClient.

We also reconstructed the early bound file with CrmSvcUtil.exe, and this is where we're having some issues. The current script we use to run the exe had a parameter for code customization referencing Microsoft.Xrm.Client, so we removed that parameter. The file was generated apparently correctly, but after testing our applications, some things seemed off. After some searching, it seems like those errors are caused by the removal of the code customization parameter.

This is the parameter that we removed : /codeCustomization:"Microsoft.Xrm.Client.CodeGeneration.CodeCustomization, Microsoft.Xrm.Client.CodeGeneration"

So, is there a replacement for the Microsoft.Xrm.Client code customization when using CrmSvcUtil.exe to generate early bound code for Dynamics 365 ?

Thanks.

*This post is locked for comments

I have the same question (0)

All responses (12)

Answers (0)

Gopalan Bhuvanesh 11,401 on at

Like (0)

Report

Did you consider using XrmToolbox to generate the same early bind classes.

www.xrmtoolbox.com/download.html

Was this reply helpful? Yes No
Suggested answer

Daryl LaBar 500 Most Valuable Professional on at

Like (0)

Report

There is no Microsoft.Xrm.Client assembly any more. No replacement either. In order to use the newest version of the CrmSvcUtil you'll have to add config options to reference the older assembly. The Early Bound Generator in the XrmToolBox can do this for you. Although I'd recommend abandoning it all together.

Was this reply helpful? Yes No
Mick Devine 10 on at

Like (0)

Report

Hi Daryl

Can you please clarify what you mean by "Although I'd recommend abandoning it all together." I'm struggling to find out how to generate these classes without using CrmSvcUtil. is there something I'm missing?

Appreciate your thoughts.

cheers, Mick

Was this reply helpful? Yes No
Daryl LaBar 500 Most Valuable Professional on at

Like (0)

Report

@Mick Devine

Microsoft.Xrm.Client added a new Entity base that inherited from the default Entity. It was an optional switch that could be used to enable the earlybound entities to be created with this different base class. This has been deprecated and is no longer available by default, so I would recommend using the removing any references to the Microsoft.Xrm.Client dll in your code and your earlybound generation (In the earlybound generator, this would be removing the check box that says "Use Xrm Client"). So continue to use either the Early Bound Generator (which just shells out to the CrmSvcUtil) or just the straight CrmSvcUtil.

Was this reply helpful? Yes No
Community Member on at

Like (0)

Report

Hi Daryl LaBar,

Would you be able to clarify what exactly has been deprecated? I've recently noticed that one of our legacy apps has a bunch of classes that inherit from Microsoft.Xrm.Client for early binding purposes (all our other apps were migrated to Microsoft.Xrm.Tooling several years ago but for some reason this one wasn't). However the CrmSvcUtil command line that was used to create the early bound classes doesn't include any references to Microsoft.Xrm.Client in the /codeCustomization parameter (such as in the original question), which if I am understanding this correctly is the 'switch' you are talking about? Instead the parameter is as follows:

/codegenerationservice:"DLaB.CrmSvcUtilExtensions.Entity.CustomCodeGenerationService,DLaB.CrmSvcUtilExtensions"

So I'm a little confused as to whether our app will be affected by the deprecation or not? NB I'm assuming it is the 'switch' that has been deprecated as I'm struggling to find anything on-line about Microsoft.Xrm.Client being deprecated ie no mention of it in Microsoft's official documentation:

docs.microsoft.com/.../mt742088(v=crm.7)

Thanks.

Was this reply helpful? Yes No
Daryl LaBar 500 Most Valuable Professional on at

Like (0)

Report

The whole Microsoft.Xrm.Client.dll has been deprecated. It hasn't been updated on Nuget since 2015: www.nuget.org. The EarlyBoundGenerator removed support for it back in March of 2020: Early Bound Generator Issue So if you're using the latest version of the EBG, you won't have any issues. If it's older and you have the flag enabled for UseXrmClient, you'll most likely get build errors.

Also note that your link is to the docs site which is not being updated, and the "Recommended Version" gives a 404.

Was this reply helpful? Yes No
Community Member on at

Like (0)

Report

Hi Daryl LaBar,

Many thanks for the quick response and the info on EBG. I guess my issue now is more around Microsoft.Xrm.Client!

I only starting using Dynamics in 2019 but my understanding from reading various on-line articles is that the CRM 2015 SDK was the last one to include Microsoft.Xrm.Client and when CRM 2016 SDK came along Microsoft.Xrm.Client was dropped in favour of the Microsoft.Tooling framework. Having said that it appears the Microsoft.Xrm.Client NuGet Package continued to be developed until 2017 - www.nuget.org/.../7.0.1

Clearly Microsoft stopped distributing Xrm.Client in their SDK and stopped any new development on it but did they actually deprecate it? The reason I am a little skeptical is that our application still compiles and runs in a production environment without issue which doesn't tally with the object being fully deprecated.

Also my understanding of Microsoft deprecations is that they always publicise anything to be deprecated about a year in advance. Maybe I am looking in the wrong place but I can't find any official Microsoft article to say that Xrm.Client is deprecated. If you were able to point me in the direction of an article that would be most appreciated as that is the piece of the jigsaw I am missing.

NB The issue I have is that the application in question has been ear marked for a complete redevelopment away from Dynamics but for various political reasons the re-write project has never happened. So we are currently in limbo unable to move it to Microsoft.Tooling, unless of course I can provide evidence that Microsoft are going to pull the plug on it...

Was this reply helpful? Yes No
Daryl LaBar 500 Most Valuable Professional on at

Like (0)

Report

I reached out to MS and was told it was deprecated in 2014/2015 and was in the official docs at the time. The deprecation message was probably lost through the few renaming's and migrations. They're looking into the possibility of adding it to the not supported doc.

Was this reply helpful? Yes No
Community Member on at

Like (0)

Report

Thanks Daryl. Was going to reach out to our MS people but looks like you beat me to it!

Would make sense for MS to give this issue a bit more visibility...

Was this reply helpful? Yes No
Daryl LaBar 500 Most Valuable Professional on at

Like (0)

Report

Judging by the fact that you're the only one to comment on this post in almost half a decade, I'd say it's safe to consider yourself a unicorn, and let MS focus on something else '.

Was this reply helpful? Yes No