You’re offline. This is a read only version of the page.
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
Daryl LaBar - BTW I think I've found a bug in your Early Bound Generator around the "Invalid CSharp Name Prefix" flag for Option Sets.
Have raised it as an issue in the GitHub repo as it would be off topic here:
https://github.com/daryllabar/DLaB.Xrm.XrmToolBoxTools/issues/287
Thanks I'll take that as a compliment!
I can't take all the credit though - have to thank my predecessor for sticking his head in the sand for several years!
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 '.
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...
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.
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...
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.
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.
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.
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
Stay up to date on forum activity by subscribing. You can also customize your in-app and email Notification settings across all subscriptions.
#1
André Arnaud de Cal...
291,240
Super User 2024 Season 2
#2
Martin Dráb
230,149
Most Valuable Professional
#3
nmaenpaa
101,156
Share
Report
All responses (
Answers (