Microsoft Dynamics 365 SDK Core Assemblies .NET Core Porting Error

Question

When trying to use Microsoft Dynamics 365 SDK Core Assemblies in a .NET Core 2.0 project, the following error occurs at runtime simply by using Microsoft.Xrm.Sdk:

TypeLoadException: Could not load type 'System.ServiceModel.Description.MetadataConversionError' from assembly 'System.ServiceModel, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'.

It looks like the Core Assemblies (Microsoft.Xrm.Sdk.Client) may simply not be compatible with anything other than ~net4x.

Is there any obvious way to get around this error or load the WCF System.ServiceModel class/interfaces needed by Microsoft.Xrm.Sdk in the context of target netcoreapp2.0? Is it possible to use Microsoft.Windows.Compatibility to bridge the gap? It looks like the Microsoft.Windows.Compatibility pack documentation indicates Windows Communication Foundation (WCF) classes/interfaces are "available". How can I use the compatibility pack to perhaps load System.ServiceModel.Description?

Thank you for any help you can provide!

Answer 1

I tried all possible things and can say that SDK, ServiceModel etc are not compatible with .net core and never will be, according to multiple discussions on github. However, i was able to do this:

• Use XrmToolBox and crmsvcutil.exe to generate models (optional)
• place them in netstandard2 project
• reference XRM SDK from nuget
• SDK works under .net core in part where LINQ queries and raw QueryExpressions are translated to subclasses of OrganizationRequest
• write custom IOrganizationService which serializes OrganizationRequests and sends them to some other app
• Other app is .net core web api which references that project and XRM SDK, but runs on full framework on windows and executes actual requests, serializes responses and sends them back.

IMPORTANT EDIT: I found out that SDK 2016 doesn't work reliably in .net core on linux due to various reasons, and stopped at 2011 (nuget package is Microsoft.Xrm.Sdk.2011). It works fine except in one case: whe you do context.AddObject and pass an Entity with no ID. SDK relies on p/invoking native Windows library to create sequential UUID and crashes on Linux. You can overcome this by setting ID prior to calling .AddObject().