Announcing the .net Core SDK for Common Data Service (CDS) - External Client Development

[MattB-MSFT]

This Post has been superseded by net-SDK-for-Dataverse-Dataverse-ServiceClient 

Folks, 

As many of you know, we have a existing .net full framework SDK that we provide for folks to develop client applications that communicate with CDS.  This SDK has existed for a long period and arose from the Dynamics 365 aspects of our platform. 

We have continued to support this SDK over the last many years over many versions of our platform.   

We have been working to update this SDK package to better address the needs of the current platform and the technologies that many of our partners who develop client applications to integrate with the Power Platform use.   We are now ready to share this with the larger community for testing and feedback. 

Today we have posted the alpha version of the Microsoft.Powerplatform.Cds.Client on nuget.  along with a few additional packages that we are using to split out the Dynamics Sales / Service and Marketing centric messages and helpers from the core CDS platform SDK

This version of the SDK libs supports the following and has the following notices: 

1. .net full framework 4.6.2, 4.7.2, 4.8 and .net core 3.0, 3.1 
2. We are supporting only Client Secret / Cert flows for .net core.  On .net framework additionally we support OAuth User flows
3. We are shipping the initial drop using ADAL.net for the Auth Lib.   We MAY change to use MSAL shortly 
   1. MSAL would enabled us to support User Interactive flows on .net core. 
4. The Namespaces of areas WILL change.  We do not know what they will change too just yet but they will change before we “release” this.
5. The Assembly Names Will likely change at least once more. 
6. The Message types that are part of the client have been reduced to CDS Core server messages only.  Things like “QualifyLeadRequest” have been removed to their own Nuget package ( Microsoft.Dynamics.Sdk.Messages ) 
7. We will likely ship more extension packages that will contain the “CRM” messages,  though over time, we will likely split the namespaces of those messages up based on service line,  think Field Service or Sales or Customer Service, etc..
8. Plugin Development using this Client is NOT supported at this time. 

We have pushed the first version up to nuget,  its tagged as preview and I encourage you to read the release notes we provide with the nuget packages. As with most of our Nuget packages that are intended as tools or for developer consumption, we extensively comment in release notes. 

Samples and such will be updated overtime on the PowerApps Samples GitHub Site as we move forward with the evolution of this capability.   That said, any of the existing CrmServiceClient samples can be used as a base to start.

From a scenario point of view,  we are particularity interested in any issues or challenges when using these library in either Asp.net Core or Functions scenarios. 

Links for the packages:

https://www.nuget.org/packages/Microsoft.Powerplatform.Cds.Client

https://www.nuget.org/packages/Microsoft.Powerplatform.Cds.Client.Dynamics

https://www.nuget.org/packages/Microsoft.Dynamics.Sdk.Messages

for 99% of your applications working against Dynamics, you should only need Microsoft.Powerplatform.Cds.Client and Microsoft.Dynamics.Sdk.Messages.

if your working against CDS Only,  you should only need Microsoft.Powerplatform.Cds.Client.  If you do not experience that, or find missing messages in the CDS only scenarios, please let us know. 

Note: Please be aware that during the Alpha \ Beta phases, these nuget packages are not supported via official channels. 

Support is aware of them, however you will likely be directed back to the community forums for support during the Alpha \ Beta phases.  A number of our dev's and PM's do monitor this channel and can respond to questions and feedback. 

As we progress this process it is our intent to deprecate then retire the older Microsoft.Xrm.Tooling.* Packages and replace them with updates built on this new set of Nuget Packages. 

Thanks All, and we look forward to your feedback on this.

Update:  We have setup a github issues site to track issues for this effort: 

Update#2:  We have now begun posting the code for the CdsServiceClient on this git Hub repro for reference. 

Please find the site here: https://github.com/microsoft/PowerPlatform-CdsServiceClient 

MattB-MSFT.  

[Artem_Grunin]

@MattB-MSFT, why not to enable the following old tech from Microsoft's Jeffrey Richter: https://blogs.msdn.microsoft.com/microsoft_press/2010/02/03/jeffrey-richter-excerpt-2-from-clr-via-c...:

Then add these DLLs to your Visual Studio project. For each DLL file you add, display its properties and change its “Build Action” to “Embedded Resource.” This causes the C# compiler to embed the DLL file(s) into your EXE file, and you can deploy this one EXE file. At runtime, the CLR won’t be able to find the dependent DLL assemblies, which is a problem. To fix this, when your application initializes, register a callback method with the AppDomain’s ResolveAssembly event.

It works like a charm and has zero impact on build time. There are tools like this https://github.com/Fody/Costura that make "merging" setup a single package installation step. This one use Einar Egilsson's suggestion to use module initializes to enable this tech for DLL's as well.

Unfortunately, we can't access ResolveAssembly event in Sandbox, but it works on-premise for not isolated plugins. If you can't enable this event for security reasons, you can add appropriate resolver for us and everybody win.

p.s. .NET Core 3 should support single assembly compilation, don't it? If .NET Core + Standard is our future, I guess, we can leave with ILMerge/ILRepack for a while 🙂

[Anonymous]

Hello @MattB-MSFT  @BetimBeja ,
First thank you guys for you answer, it was very useful 😄
the Secret Client authentification work perfectly in Windows, but in Linux i get error :'(

Microsoft.Powerplatform.Cds.Client.Utils.CdsConnectionException: Failed to connect to Common Data Service
---> System.AggregateException: One or more errors occurred. (The request channel timed out attempting to send after 00:02:00. Increase the timeout value passed to the call to Request or increase the SendTimeout value on the Binding. The time allotted to this operation may have been a portion of a longer timeout.)
---> System.TimeoutException: The request channel timed out attempting to send after 00:02:00. Increase the timeout value passed to the call to Request or increase the SendTimeout value on the Binding. The time allotted to this operation may have been a portion of a longer timeout.
---> System.TimeoutException: The HTTP request to 'https://vsmptest.crm4.dynamics.com/XRMServices/2011/Organization.svc/web?SDKClientVersion=9.0.45.79' has exceeded the allotted timeout of 00:02:00. The time allotted to this operation may have been a portion of a longer timeout.
at System.ServiceModel.Channels.HttpChannelFactory`1.HttpClientRequestChannel.HttpClientChannelAsyncRequest.SendRequestAsync(Message message, TimeoutHelper timeoutHelper)
at System.ServiceModel.Channels.RequestChannel.RequestAsync(Message message, TimeSpan timeout)
--- End of inner exception stack trace ---

Cordially

[MattB-MSFT]

Folks,  we have stood up an github issues site to track issue and provide status updates for the CdsServiceClient and its surrounding bits. 

Please find the site here: https://github.com/microsoft/PowerPlatform-CdsServiceClient 

@BetimBeja I have forward the issue your describing over to the auth team to have a look,  an Anonymous response is defiantly not what we want in this situation. 

@Anonymous that looks a lot like a network issue,  are you using a Linux hosted function there? or are you hosting it on your own box?

[MarkData8]

Is there an intention of supporting additional authentication types for .NET Core before GA? We currently connect to customer's on-prem instances with and without IFDs as well as online instances, and currently the CRM SDK is the only thing holding us back from switching fully to .NET Core/Standard.

[MattB-MSFT]

We are considering supporting Active Directory Only for onPrem where ADFS is not present. 

Thanks

MattB. 

[crmdev23]

Hi Matt

Any plans to deliver an early bound generation tool for .NET Core (CrmSvcUtil)?

Thanks!

[MattB-MSFT]

The current CrmServiceUtil generates classes that work cleanly with the .net core clients. 

Insofar as building a version that will codegen based on .net core.  at this time no. 

Its not on our short term list as .net core is missing a good deal of the code dom we use to do mutilanguage generation in CrmServiceUtil. 

That said, as .net core evolves our options may change. 

Could you outline your use case for needing it?

thanks

[1233212314]

If the generated classes work with .NET core I'm fine. I don't need a .NET core based version of the tool itself.

My use case is to communicate with CDS from an Azure Function using Web API combined with early bound classes.

[MarkData8]

As far as I can tell, the new SDK will only support connecting via Web API and not SOAP, is that correct? What is the earliest version that it will connect to - 8.0?

For on-prem IFD instances with ADFS, what authentication methods are planned to be supported?

[Anonymous]

Hello @MattB-MSFT 

Can you give us an exact date of the first stable release

Thank you

Cordially