Any roadmap or release plan?

[keqli]

I am from Microsoft Dynamics 365 Commerce Team. We have a WebAPI service built on .NET Framework v4.6.1 and a Azure Function built on .NET Core v3.1. We want to build a shared library on Dataverse Client and consumed it in both places. However, the current Dataverse client v0.4.12 is based on .NET Framework >= v4.6.2 or .NET Core >= v3.0, which makes the library sharing not practical. Any suggestion to solve the problem?

Is there a roadmap or release plan (with release date) for the Dataverse Client library? Will it be migrated to target at .NET Standard 2.0 in near future, in which way our problem will be solved?

[MattB-msft]

Unfortunately we do not have a plan to support .net standard at this time. we may add it in the future as we move the infrastructure further towards a spot that does not have the dependencies that block it from .net standard today. Currently there are set of dependences that we have that are derived from parts of the .net 4.8 framework that were missed in .net standard 2.0.. as the .net team is no longer actively developing on .net standard, we do not have an opportunity to get them reincluded. They are in .net core 3+, and we will soon be shipping .net 5 and .net 6 target assemblies.

Right now, I would recommend you mulit target your library that you want to share,

The public interaction interface for the Dataverse Client is complete at this time.
Things that impact the public interface that are in development or design actively:

• We are looking at adding additionally features to it to make using the Dataverse ServiceClient more friendly to DI systems in the future,
• Will likely alter 1 of the constructors to remove the ability to pass in a OrganizationWebProxy in the future.
• We are exploring adding support to pass in a constructed IOrganizationService for backward compatibility to some of our systems. We have already done that via an internal interface and are now considering exploring it publicly.

Internally there is quite a bit going on and we should be pushing updates here soon. The internal updates are focused on further supporting the transition to the WebAPI endpoints provided by Dataverse,

We will continue to support folks here, however we are also going to open up support via the 'normal' support channels for API and SDK related items for Dataverse/PowerPlatform in the near future.

Thanks.

[hkusulja]

The date for end of support for .NET Framework and .NET Core are approaching, future is .NET 5 and .NET 6 (soon). So, if I am new to .net 5 (6 soon) then do not want to have legacy code or dependency, and is this nuget then usable or not? Does it uses Dataverse web api in backend or service / SOAP connection?

Please let us know about panning and future, so we can adjust our customers plans for development and dependency.

[MattB-msft]

This assembly is usable now, and is in active use in several of our products. the only ask we have at this point is to stay current as we are revving this codebase and providing fixes in a fairly regard bases (This current pause in releases, notwithstanding as we do some refactoring and bigger updates).

With regard to .net support, The .net team is providing support 4.6.2, 4.7.2, and 4.8 in the full framework for the foreseeable future With regards to .net core, we currently ship libs for 3.0,3.1 and test on 3.0,3.1,and 5.0

With regard to your question about which API it's using, it uses both SOAP and WebAPI right now, we are moving more of the system to use WebAPI. The public contract is mostly stable at this point aside from by Above mentioned items.

[andrew-sumner]

Regarding the comment "This assembly is usable now, and is in active use in several of our products.". The readme file states this product is still in Alpha. Our company will not let anything into production that is marked as Alpha. If this is as feature complete as you suggest, is there any reason you cannot at least go to Beta?

[andrew-sumner]

Any reply for my previous comment?

[andrew-sumner]

@MattB-msft Can you provide any assurance that it is safe to use this in production as is?

[hkusulja]

@MattB-msft you are right. .NET Framework 4.8 does not have end date for support, regarding the: https://docs.microsoft.com/en-us/lifecycle/products/microsoft-net-framework

However, .NET Core 3.1 has end of support in early 2022 according the: https://docs.microsoft.com/en-us/lifecycle/products/microsoft-net-and-net-core

So, my question is, can you reference a PowerPlatform.Dataverse.Client (github or nuget) which has dependency for .net 5 , since https://www.nuget.org/packages/Microsoft.PowerPlatform.Dataverse.Client/ does not have it

[hkusulja]

@MattB-msft can you please update us with information and timeline about .net standard / .net 5 , just to align expectations of this nuget/Client. Thank you

[MattB-msft]

Right now there is no short term plan to support .net standard hosts., You will need to either use a full framework host or a .net core host. .net 5 is supported now, and we are using it for a few internal projects. .net 4.6.2/4.7.2 and 4.8 are the mainline supported net frameworks. and we ship for .netcore 3 and 3.1 which are supported by .net 5, we will at some point soon produce a target for .net 5 and 6.

[hkusulja]

@MattB-msft .NET 5 is almost a year out in production, and .NET 6 will be in RC in few days, and 4 months it will be release and LTSC. Lot of other NuGets already have public beta/preview version supporting .NET 6 So any plans to speedup .net standard / .net 5 or .NET 6 preview native support publishing / release for the public? thank you

[MattB-msft]

.net Standard host support will not be supported due to limitations in .net standard. There is no plan that we are aware of for a future version of .net standard beyond 2.1. Thus its unlikely that the fixes we need there will ever be added.

.net 5 is supported now and folks can readily use it with the 3.1 target we provide, there is no apparent need for us to ship a .net 5 target specifically, are you being blocked by something consuming the 3.1 target in a .net 5 project?

.net 6 is still being refined and we are providing feedback on it to the .net team. will declare support for it after its shipped.

[eBerdnA]

@MattB-msft as @andrew-sumner already asked this and got no (final) answer, is there anything "official" you can say about using this library in a production environment? So, do we need to regard this library as still in alpha-state or is ready for production?

[rgx91]

We need this information really, it is reliable enough to use it in production softwares or not? If not, there are other solution which let my .Net.Core application connect to dataverse programatically?

[andrew-sumner]

@rgx91 I've been speaking to a Microsoft MVP within our company who has recommended we go ahead and use it based on his chats with the D365 community.

Apparently this is a big topic of discussion with the community split between those that are sticking with V1 function apps, and those that are using this and moving to .Net Core.

I think the alpha label is causing more concern than it's worth and I suspect it's only being kept so that the team are free to make any changes they want without worrying about backwards compatibility.

[MattB-msft]

We are in process in updating the front read me to remove the Alpha tag from it. Should be done in a day or so. We are actively supporting this library now for several of our internal projects and external tools, ( the PowerPlatform CLI, VS code, others... )..

@rgx91 Insofar as production ready, Yes. it is. and is being used for several of our internal high volume services supporting the PowerPlatform itself. That said, you can always result back to using the WebAPI/trimmed $metadata + an oData client builder directly if you choose.

Support wise, We would like to keep support for it mainly here on our Issues page as that is what the dev team is actively watching. However Tickets raised on it via normal support channels will find their way to the owning team :)

[hkusulja]

Reverting back to oData client builder is issue with very big metadata for Dynamics products. Support here and github open source is fine. I think i will have info about using it in new project with .net 5 on windows host, but hope to see .net standard and .net 6 in few months.

[MattB-msft]

@hkusulja .net 6 is not out of preview just yet :). That said, it does work on .net 6 and we are using .net 6 in some of our internal testing.

The client currently works on Windows, Mac and Linux hosts,
We build and run tests on Linux hosts currently as part of our checkin process :)

Regarding oData meta size. Yes, we are well aware of that, there are a few tools that are available to trim this down and we are considering baking one into our codegen tool (currently called CrmServiceUtil ). Hopefully we will have more to say on that in the near future.

[MattB-msft]

Update here folks: .net 6 is out now and we will be updating our front page with Stated Support for .net 6.

[hkusulja]

@mattb-msft thanks for the update, any info about metadata size issue and CrmServiceUtil ?

[MattB-msft]

@hkusulja we are still a ways away on that, I do not want to get your hopes up that for a short term solution there.

MattB

[MattB-msft]

Folks on this thread, As an Update, 0.6.x is expected to be our final minor update prior to 1.0,
Our doc's folks will soon be starting on this version in preparation for release docs at release time.

[MattB-msft]

@mattb-msft thanks for the update, any info about metadata size issue and CrmServiceUtil ?

We shipped (today) an update to the crmsvcutil cmd line tool to allow for granular class building, splitting entity files, and a number of other features. You will find that in the Microsoft.crmsdk.coretools 108+ nuget packages

[hkusulja]

@MattB-msft can you please write in short, benefit of using REST API / OData using HttpClient, vs using Service (.svc) using this Dataverse Service Client ? (Performance, features, support lifetime etc.) So, I can show this to my managers for future decision for a new projects and which direction in future should project choose.

Thank you, Kind regards

[MattB-msft]

There are benefits to both approaches @hkusulja, Its more a function of what your comfortable with and what you want to get out of it.

In the case of the WebAPI, which is an OData 4.0 protocol (not Rest) This is our open standards API, its intended for developers that are using languages other than .net, or for developers that want to control all aspects of the client and communications channel with Dataverse. Fundamentally this is a 'wire protocol' api, requiring the user to understand how to use and manage that protocol.

• You have total control over the client and wire communication's, allowing you to use many OS tools and libs to help you build a client.
• You can purpose build the client for specific use cases.
• You have to create that client and maintain it. - there are lots of OSS tools to help you here but you have to do it
• You can build types and translations between each to translate from JSON to strong type. several tools to help here.
• You implement and control authentication related items.
• in general, its very helpful if you are familiar with OData/REST type clients first

In the case of the Dataverse ServiceClient, This is an opinionated .net client, it exposes the organization model API provided by Dataverse. This client manages all aspects of communication with Dataverse and other PowerPlatform services. allowing the developer to focus on whatever the logic is that they want to implement vs dealing with the wire protocol(s) themselves.

• It allows you to focus on creating applications that interface with Dataverse without dealing with wire protocol
• it exposed the object model API provided by Dataverse directly, allow for strong type mapping and linq support based on generated models, using our supplied tooling.
• it has built in support for throttling, retry, networking and other conditions that are specific to Dataverse behaviors
• it will scale itself up or down feature wise based on the connected Dataverse instance.
• it provides telemetry and logging support that you can attach to as needed.
• it will create and manage access tokens and lifecycle, it does allow for end developers to override this behavior.
• Microsoft regularly ships updates to these clients for feature and security
• It exposed several different functions and features across serval services.

In the case of TSQL This is a SQL based Query Service, that returns tabular results, usable in SQL management studio and or with MSSQL based connectors. it is for read / query only.

Hope that helps clarify how we have organized our API and SDK.

[rafek1241]

Hi @MattB-msft, Can you tell us when do you plan to make it usable for plugin development (dynamics CRM)? I hope we will be able to update our project soon from .net 4.X to newer versions.

[MattB-msft]

@rafek1241 We are considering this for the future; however, we have no short-term plans to support beyond .net framework 4.6.2 You will see us officially support 4.6.2 - 4.8 first.

This sort of change is a substantial breaking change across our hosting, tooling and developer ecosystem, and thus is being approached with extreme caution.

Thanks

[MattB-msft]

Closing this thread out as we have shipped the ga version of the client.

[hkusulja]

Can you please confirm this is resolved?

[rafek1241]

I can't because I changed my workplace. Sorry! =(