Showing results for 
Search instead for 
Did you mean: 

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

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




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 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 Core or Functions scenarios. 


Links for the packages:


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: 




Frequent Visitor

@MattB-MSFT wrote:


Plugin Development using this Client is NOT supported at this time. 

Is this expected to be supported in the future?


Also, why are the new packages not .NET Standard-based? 

Shouldn't that enable them to be used for plugin development, as well as client scenarios? Meaning they would still continue to be executed on .NET Framework inside CDS, but also on .NET Core outside the platform.


ILMerge-ability is desired as well. I understand Microsoft does not support this, but in practice it is being used on production in a LOT of projects. I'm not sure if this would be affected 


On a side note: can we please switch to Github for these discussions? I understand there is a low/no-code side of the platform intended for people who might feel comfortable with this forum, but for us code breathers it really isn't. This is the third time I type this stuff here because my post was rejected due to some weird HTML stuff, and then I got these errors after trying to login.


And btw, are you ever planning to open source the SDKs? my reverse-engineered version of the plugin debugger integrated right into Visual Studio yearns to become legal so it can be shared with the wider community.

Thanks for your feedback,  and In answer to your questions:
( bit of a book here 😉 )
Why not .NET standard:
.NET Standard 2 is missing several methods from .NET framework 4.8 that our SDK requires. The .NET standard team is aware of this and is planning to address it in the future.  When they have support for it, we will provide a target for .NET standard.
Plugin/Sandbox in general:
There are a number of enhancements and changes in flight with the Plugin system currently.  Support for tech stack's other .NET Framework are being consider, but require substantial investment to bring to market and thus take time.   .NET Core is one of the tech stack's being looked at.
We are logically separating External Client development from Plugin development, and we wanted to bring the .NET core based clients tech to market as soon as we could make it viable.  Additionally, We are in working on splitting up the Namespaces, message names, and in some cases renamespacing sections of our platform away from the combined "crm" model to more closely match how we are building, servicing, and operating the system.  ( thus the Alpha tag on the current release train ). 
With regard to ILMerge: 
This comes up a lot and I will try to explain the reasoning here.
The reason ILMerge is used is one of the key reasons for several enhancements in our Plugin system currently in desgin.  ILMerge is unsupported, its unserviced and is technically unowned inside Microsoft.  It was a Microsoft research project that was never taken forward and those updates that have been done have been done by teams using it internally.  That it works as well as it does today is a nod to the programmers of the .net framework and the author of the ILMerge tool.   "We" cannot officially support it for use with our platform as the PowerPlatform team cannot take on the responsibility for bug fixing ILMerge itself, which would be the byproduct of PowerPlatform's Official support of it.  That said, we do not actively block the use of it in our platform because we know that its require for some scenarios currently.
With regard to OSS and GitHub:
It’s a fair ask,  the reason we didn’t do it at this time was that to take this discussion to GitHub would require us to have a Repro on GitHub with the source posted, we could do an empty repro that would not really do much more then this board.  To get to the code posted state requires us to setup an large amount of process and infrastructure to comply with our commitments around our SDL policies that we do not have time to do at this time.   That said we DO want to do it at some point in the future.  it really a matter of getting the aforementioned process and overhead support in place to make posting to git hub more useful than just having a non-compiling copy of the code post there that folks can comment on.
With regard to your comment about reversing the PRT and using part of it in another project:
I get the use cases for this, however to put this in our prospective: 
We OSS'ed our login code , several tools and the prt in CRM v5 and v6.  Because that code exists, we spend a lot of time on support cases where the primary reason is that someone took the v5 or v6 code and integrated it a custom tool set or project and sold or used that in a deployment, due to the changes we have made of the last 6 years or so the code stopped working and we are asked to solve it for them.  This is why we invested so heavily into Nuget Modules over the last 7 years or so to allow folks to just take an update to a nuget package to stay current, and we worked very hard to maintain backward compatibility in the client interface code ( CrmServiceClient and such ).  
Specifically with regard to the debugger of the PRT,  this is actually something we are discussing turning into its own Nuget package vs shipping with PRT as we do today.   Please send me a direct message with your use case, I would like to understand what your working on there and why you have made some decisions.  It could be we can share how to use the debugger.exe that is part of PRT natively with you and avoid you have to have forked the code.
Hope that helps clear up some of our decisions here.




First of all thanks a lot for hearing me. I will try to address your thoughts with as much detail and as clearly as possible. This will probably get long too 😉


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 


This is excellent. IMO a much wider separation needs to be drawn between the CDS platform and the Dynamics 365 product. I mean both in the documentation and in a practical sense such as this package separation. Keep doing more of this please.

As an example: I've been working for more than 4 years now in both existing and greenfield projects where the usage of Common Data Model entities (Opportunity, Lead, etc) and vanilla "Dynamics 365" functionality is practically ZERO and instead we have a lot of custom business functionality supported by custom industry-specific or client-specific data models and business processes. 


TL;DR: we're using CDS as a business application platform and don't care very much about CRM functionality and default entities. Keeping these aspects as separate as possible is a plus for us.


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


I'll report back as soon as I get a proof of concept up and running on Azure Functions V3 on .NET Core using the new CDS Nugets. At this time we're stuck on Azure functions V1 precisely due to the need to target .NET Framework and use Microsoft.Xrm.Sdk.dll


There are a number of enhancements and changes in flight with the Plugin system currently


It would be awesome if you could communicate the general technical roadmap and would be willing to discuss it with the community. This is a philosophical matter, and might be a big change, but a lot (most?) of the Microsoft dev stack has converted in recent years to a workflow where the will make their roadmap public and are willing to discuss it with the larger community (think how the C# language team went from the Anders/Mads era of "benevolent dictatorship" to the current Github-all-the-things approach). As a developer who invested a decade exclusively in the MS stack, this is tremendously valuable.


Support for tech stack's other .NET Framework are being consider


I imagine this has to do with getting plugins out-of-process in the form of Azure Functions or something similar? If so, keep in mind it is important to maintain existing functionality (synchronous, single transaction, friendly business error messages for the end user, and so on)


To be fair though, this might make sense for greenfield projects, but there's no way existing projects with heavy business logic will migrate to a non-C# tech stack. For instance it makes no sense for me to write a CDS plugin in javascript, but that's mainly because I hate js and dynamic languages in general.


NET Core is one of the tech stack's being looked at


.NET Core, on the other hand, makes a lot of sense as a target platform for both client and in-process (plugins) CDS code, because it enables us to design application architectures where Model classes and Business Logic is shared among these, and I no longer care about whether my business logic executes in a plugin, or inside an azure function, as long as I have a valid IOrganizationService instance to work with.


For instance: I have this abstraction which makes it pretty much transparent for application code whether it's running in an Azure Function or inside a regular plugin.


We are logically separating External Client development from Plugin development


Please consider that it is very important to maintain the current compatibility level. I don't want to have to differentiate plugin code for business logic from other business logic that executes elsewhere. The entity model is the same, the IOrganizationService interface is the same, and whatever abstractions I write on it are the same. As an aside, the LINQ provider is of critical importance too and it is critical that it will continue to work in all currently supported scenarios.


I will PM you a solution diagram to illustrate our current preferred architecture for CDS based applications.


With regard to ILMerge


I understand and agree with everything you've said about this subject. If the platform enables me a different, supported way to reference my own assemblies/Nuget packages inside plugins I will gladly get rid of ILMerge too ;). When we have 30+ plugins in a single VS Solution each build/rebuild becomes slow because it has to ILMerge 3 or 4 assemblies into each one of the 30+ plugins 😞


Again, thanks for taking the time to read my post, I greatly appreciate that.
I will email you about the debugger and with additional details of the designs and tools I've come up with during these years working on XRM/CDS.


btw, you guys rock so much. Keep going.





Regarding Plugins:

we do not have much to say specific feature wise on this right now aside from "there is a good deal of work going on". When we get closer to knowing what lands and when, we will start talking about it publicly 🙂


Regarding non .net plugins types…

You would be surprised the number of requests we get to support non .net languages 😊 Non-net plugins will necessarily have a different method of interaction.


With regard to compatibility with the .net framework in the alpha, The current alpha is fully compatible with all the features of the full framework system, including Linq,



Amazing news that we finally have .net core support!!

Will we see async/await being added for organizationrequests? Azure Functions, for instance, are billed by cpu time, memory usage etc... Would be great to not have to take cpu time while waiting for the response.
New Member

Great stuff, have many customers asking for .Core compatibility, so looking forward to this becoming a non beta. Will start looking into this right away. 


What is the outlook of this running on a on-premise installation? Specifically one running AD Auth. I believe this would work with claims, but could not get it working with AD auth. 

@Toftager  From memory (it's a while since I've done it) Certificates work better than shared secrets in the AD world.

Have you followed all the steps in  as it's possible you may be missing a step out.

If this post has answered your question please consider it for "Accept as Solution" or if it has been helpful give it a "Thumbs Up".

Plugins are based on WCF Message Pipeline, are CDS re-engineering away from WCF on the server side in order to be reborn into the Cloud?

Frequent Visitor

Any love for F#?
Currently, the plugin system doesn't recognize FSharp.Core.

It would be great to register plugin written in F#.

Helpful resources


Celebrating the May Super User of the Month: Laurens Martens

  @LaurensM  is an exceptional contributor to the Power Platform Community. Super Users like Laurens inspire others through their example, encouragement, and active participation. We are excited to celebrated Laurens as our Super User of the Month for May 2024.   Consistent Engagement:  He consistently engages with the community by answering forum questions, sharing insights, and providing solutions. Laurens dedication helps other users find answers and overcome challenges.   Community Expertise: As a Super User, Laurens plays a crucial role in maintaining a knowledge sharing environment. Always ensuring a positive experience for everyone.   Leadership: He shares valuable insights on community growth, engagement, and future trends. Their contributions help shape the Power Platform Community.   Congratulations, Laurens Martens, for your outstanding work! Keep inspiring others and making a difference in the community!   Keep up the fantastic work!        

Check out the Copilot Studio Cookbook today!

We are excited to announce our new Copilot Cookbook Gallery in the Copilot Studio Community. We can't wait for you to share your expertise and your experience!    Join us for an amazing opportunity where you'll be one of the first to contribute to the Copilot Cookbook—your ultimate guide to mastering Microsoft Copilot. Whether you're seeking inspiration or grappling with a challenge while crafting apps, you probably already know that Copilot Cookbook is your reliable assistant, offering a wealth of tips and tricks at your fingertips--and we want you to add your expertise. What can you "cook" up?   Click this link to get started:   Don't miss out on this exclusive opportunity to be one of the first in the Community to share your app creation journey with Copilot. We'll be announcing a Cookbook Challenge very soon and want to make sure you one of the first "cooks" in the kitchen.   Don't miss your moment--start submitting in the Copilot Cookbook Gallery today!     Thank you,  Engagement Team

Announcing Power Apps Copilot Cookbook Gallery

We are excited to share that the all-new Copilot Cookbook Gallery for Power Apps is now available in the Power Apps Community, full of tips and tricks on how to best use Microsoft Copilot as you develop and create in Power Apps. The new Copilot Cookbook is your go-to resource when you need inspiration--or when you're stuck--and aren't sure how to best partner with Copilot while creating apps.   Whether you're looking for the best prompts or just want to know about responsible AI use, visit Copilot Cookbook for regular updates you can rely on--while also serving up some of your greatest tips and tricks for the Community. Check Out the new Copilot Cookbook for Power Apps today: Copilot Cookbook - Power Platform Community.  We can't wait to see what you "cook" up!      

Tuesday Tip | How to Report Spam in Our Community

It's time for another TUESDAY TIPS, your weekly connection with the most insightful tips and tricks that empower both newcomers and veterans in the Power Platform Community! Every Tuesday, we bring you a curated selection of the finest advice, distilled from the resources and tools in the Community. Whether you’re a seasoned member or just getting started, Tuesday Tips are the perfect compass guiding you across the dynamic landscape of the Power Platform Community.   As our community family expands each week, we revisit our essential tools, tips, and tricks to ensure you’re well-versed in the community’s pulse. Keep an eye on the News & Announcements for your weekly Tuesday Tips—you never know what you may learn!   Today's Tip: How to Report Spam in Our Community We strive to maintain a professional and helpful community, and part of that effort involves keeping our platform free of spam. If you encounter a post that you believe is spam, please follow these steps to report it: Locate the Post: Find the post in question within the community.Kebab Menu: Click on the "Kebab" menu | 3 Dots, on the top right of the post.Report Inappropriate Content: Select "Report Inappropriate Content" from the menu.Submit Report: Fill out any necessary details on the form and submit your report.   Our community team will review the report and take appropriate action to ensure our community remains a valuable resource for everyone.   Thank you for helping us keep the community clean and useful!

Community Roundup: A Look Back at Our Last 10 Tuesday Tips

As we continue to grow and learn together, it's important to reflect on the valuable insights we've shared. For today's #TuesdayTip, we're excited to take a moment to look back at the last 10 tips we've shared in case you missed any or want to revisit them. Thanks for your incredible support for this series--we're so glad it was able to help so many of you navigate your community experience!   Getting Started in the Community An overview of everything you need to know about navigating the community on one page!  Community Links: ○ Power Apps ○ Power Automate  ○ Power Pages  ○ Copilot Studio    Community Ranks and YOU Have you ever wondered how your fellow community members ascend the ranks within our community? We explain everything about ranks and how to achieve points so you can climb up in the rankings! Community Links: ○ Power Apps ○ Power Automate  ○ Power Pages  ○ Copilot Studio    Powering Up Your Community Profile Your Community User Profile is how the Community knows you--so it's essential that it works the way you need it to! From changing your username to updating contact information, this Knowledge Base Article is your best resource for powering up your profile. Community Links: ○ Power Apps ○ Power Automate  ○ Power Pages  ○ Copilot Studio    Community Blogs--A Great Place to Start There's so much you'll discover in the Community Blogs, and we hope you'll check them out today!  Community Links: ○ Power Apps ○ Power Automate  ○ Power Pages  ○ Copilot Studio    Unlocking Community Achievements and Earning Badges Across the Communities, you'll see badges on users profile that recognize and reward their engagement and contributions. Check out some details on Community badges--and find out more in the detailed link at the end of the article! Community Links: ○ Power Apps  ○ Power Automate  ○ Power Pages  ○ Copilot Studio    Blogging in the Community Interested in blogging? Everything you need to know on writing blogs in our four communities! Get started blogging across the Power Platform communities today! Community Links: ○ Power Apps  ○ Power Automate  ○ Power Pages  ○ Copilot Studio   Subscriptions & Notifications We don't want you to miss a thing in the community! Read all about how to subscribe to sections of our forums and how to setup your notifications! Community Links: ○ Power Apps  ○ Power Automate  ○ Power Pages  ○ Copilot Studio   Getting Started with Private Messages & Macros Do you want to enhance your communication in the Community and streamline your interactions? One of the best ways to do this is to ensure you are using Private Messaging--and the ever-handy macros that are available to you as a Community member! Community Links: ○ Power Apps  ○ Power Automate  ○ Power Pages  ○ Copilot Studio   Community User Groups Learn everything about being part of, starting, or leading a User Group in the Power Platform Community. Community Links: ○ Power Apps  ○ Power Automate  ○ Power Pages  ○ Copilot Studio   Update Your Community Profile Today! Keep your community profile up to date which is essential for staying connected and engaged with the community. Community Links: ○ Power Apps  ○ Power Automate  ○ Power Pages  ○ Copilot Studio   Thank you for being an integral part of our journey.   Here's to many more Tuesday Tips as we pave the way for a brighter, more connected future! As always, watch the News & Announcements for the next set of tips, coming soon!

Hear what's next for the Power Up Program

Hear from Principal Program Manager, Dimpi Gandhi, to discover the latest enhancements to the Microsoft #PowerUpProgram, including a new accelerated video-based curriculum crafted with the expertise of Microsoft MVPs, Rory Neary and Charlie Phipps-Bennett. If you’d like to hear what’s coming next, click the link below to sign up today!  

Users online (3,125)