PowerPlatform-DataverseServiceClient: This library is not usable unless/until CDS plugins properly support it
All of my CDS-based projects (i.e all projects of my company, since we exclusively provide CDS-based solutions, which I love) look like this:
- MyProject.Model
- MyProject.BusinessLogic
- MyProject.Plugins
- MyProject.Api
- Etc...
The Model project will contain early-bound entities which derive from Microsoft.Xrm.Sdk.Entity. Then, the BusinessLogic layer contains all business logic for the entire project, which uses the entities defined above. Then the rest of the solution will consume these 2.
But now I have 2 versions of Microsoft.Xrm.Sdk.Entity, from 2 different assemblies, that I need to derive from depending on whether I’ll be using them for a plugin or for an external component such as a Web API, Azure WebJob or Function, etc. This effectively means that I now have 2 different, incompatible set of entities, which completely destroy all possibilities of reusing anything or having a common base layer.
In an ideal scenario (apart from running the entire CDS platform on .NET Core, which seems far fetched), this library should target .NET Standard 2.0 and be compatible with both .NET Framework 4.x assemblies (which can then be used for plugins) AND .NET Core 3.0, for any usage anywhere outside the CDS platform, such as Azure Functions and so on.
About this issue
- Original URL
- State: closed
- Created 4 years ago
- Reactions: 1
- Comments: 15 (3 by maintainers)
@fberasategui,
thanks for your feedback. a few comments.
If you will allow a different interpretation; We are running on a .net framework that is bedrock solid, we know how it preforms, how it breaks and where its limits are. its a low enough version that as we upgrade customers from onpremise, we do not require them to do mass recompiles of code to install plugins or talk to us. its also fully supported on .4.7.2 and .4.8. Thus seeking maximum compatibility and reliability at the detriment of being on the leading edge. (.net 4.6.2 in active support and will remain there for a number of years yet.)
Given that, We are using this client and its modifications to validate our .net core support and feature set for our strongly types SDK/API infrastructure as we move around or Infrastructure to support updating various bits of it to .net core and like languages.
We do offer direct access to our WebAPI for folks that want to go down to the wire protocol and develop there own clients.
As this client is still in Alpha we have not formalized that guidance, that said, we are doing this internally and are working out the kinks/bugs along the way.
.Net core support for plugins is blocked by this client at this time, as we are not in a position to support that server side and decided to head off the bad experience before customers and developers ran into it.
Adding to that is that we do intended to diverge Namespaces over the next year or so, similar to what you see in this package now, where the base package only has CDS core Namespaces. This will father change over time as the base namespace Microsoft.Xrm begins to change.
But to be clear, these nuget packages are intended for Client development only, not for server development.
Hi Fede,
Agree, but I think @MattB-msft mentioned that there were some technical limitations by which they had to go for a multi target package instead of targeting .net standard… given said that…
One workaround is to put your model / business logic projects into one multi target nuget package each… in that way you could consume the same package both from client applications (api, aspnet core, azure functions in .net core), AND server applications would be linked to the “old” SDK Tooling in full .net framework. For example, rather than using shared projects, we produce many nuget packages internally with both .dll’s and source code, they’re the same package, but one is aimed at external applications (.dlls) and the source package aimed at plugins / codeactivities etc.
Now, this is because even though they’re different assemblies they still share pretty much the same namespaces… but things will start to break as soon as the new CdsServiceClient repo starts to divert from the existing XrmTooling…
I’m going late to this conversation, but if you’re using Visual Studio, then would a Shared Project work for allowing for code reuse between different projects? Or are Shared Projects not supported in .net core?
@jordimontana82 the entire discussion is based on my first post, where I specify the usual solution structure I use for all my CDS based software projects.
I fully agree with you that reusable logic should be put into Nugets, IF and only if it needs to span multiple solutions/repos, but that’s not the case I’m talking about in this thread.
So… Multitarget does not need 2 packages, the one package can multi target both frameworks, here’s an example:
Don’t agree with this bit at all, from my own experience, there are many cases where business logic can be reused by at least 2 consumers and so it makes sense to put it in a nuget package…, if the change is small enough probably not worth it, fair enough, but from there to saying is completely unacceptable under any circumstance… there’s a big difference.
So yeah, multi target for the time being OR wait for a more stable release 😃