Matt:
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 Asp.net 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.
