[RFE] Microsoft.CrmSdk.Data targeting .NET Core / .NET 6.0

[fowl2]

We're using Microsoft.PowerPlatform.Dataverse.Client to incrementally move code between a plugin and an Azure Function. One of our dependencies is Microsoft.CrmSdk.Data which currently is only targeted against .Net Framework, leading to this warning:

NU1701 Package 'Microsoft.CrmSdk.Data 9.0.2.45' was restored using '.NETFramework,Version=v4.6.1, .NETFramework,Version=v4.6.2, .NETFramework,Version=v4.7, .NETFramework,Version=v4.7.1, .NETFramework,Version=v4.7.2, .NETFramework,Version=v4.8, .NETFramework,Version=v4.8.1' instead of the project target framework 'net6.0'. This package may not be fully compatible with your project.

Microsoft.CrmSdk.Data seems to work fine under .Net 6.0 despite this. Fingers crossed.

Transitively it also introduces this warning:

NU1701 Package 'Microsoft.CrmSdk.CoreAssemblies 9.0.2.42' was restored using '.NETFramework,Version=v4.6.1, .NETFramework,Version=v4.6.2, .NETFramework,Version=v4.7, .NETFramework,Version=v4.7.1, .NETFramework,Version=v4.7.2, .NETFramework,Version=v4.8, .NETFramework,Version=v4.8.1' instead of the project target framework 'net6.0'. This package may not be fully compatible with your project.

Microsoft.CrmSdk.CoreAssemblies brings in conflicting versions of Microsoft.Crm.Sdk.Proxy.dll and Microsoft.Xrm.Sdk.dll. Somehow msbuild/nuget/the sdk figures this out and the right version ends up in the output for my project (yay!) and it all seems to work.

It'd be super nice if there was a version of Microsoft.CrmSdk.Data that targets modern .Net.

Thanks!

---

PS: it's strange that Microsoft.CrmSdk.Data 9.0.2.45 depends on the Microsoft.CrmSdk.CoreAssemblies 9.0.2.42 - notice the slight version mismatch.

[MattB-msft]

Microsoft.Crmsdk.Data is only built for .net 4.6.2 and is intended for use only with the Virtual Entity system when developing a data provider.

Could you tell me what your using in the Microsoft.Xrm.Data.dll in an Azure function?

[fowl2]

To run our virtual entity provider inside the Azure function.

Calling the data source directly has much better performance.

[MattB-msft]

That's an interesting scenario.
Though we do not support pushing that capability off the platform itself, I assume then you have created an API surface (somewhat like a connector) that is interfacing between the Plugin based VE Data provider and your API Service? I would also gather your trying to do shaping before you return data to the API call which is where you're using the Microsoft.Xrm.Data.dll features?

What features from Microsoft.Xrm.Data.dll are you using?

[fowl2]

Yes we have an implementation of IOrganizationService that consults the metadata against the entity in the message to determine wether to pass it on to ServiceClient or to the data provider.

I'd have to check the code to answer what functionality we're using.

[MattB-msft]

Thanks @fowl2,
As I said, this is not a scenario we are going to support in the short term. We are not planning on shipping those libs outside of the plugin framework support structure. Once the plugin system moves forward, this will get picked up, that said, we have not public statement on that system at this time and no ETA or timeframe to disclose.

[fowl2]

Thanks for the consideration :)

For reference, it turns out we're only using the exception classes, so for our current use case we can just create our own exception classes with the same names behind an #if !NETFRAMEWORK.

At some point in the past we also used some Microsoft.Xrm.Sdk.Data.Mappings, but must have run into some limitations and found an alternative.