Support for EF Core 3.1 on .NET Standard 2.0

Discussion of open issues, suggestions and bugs regarding ADO.NET provider for Oracle
Post Reply
KRU
Posts: 5
Joined: Tue 08 Oct 2019 11:51

Support for EF Core 3.1 on .NET Standard 2.0

Post by KRU » Thu 10 Sep 2020 14:16

Hi :)


Having looked into things, EF Core 3.0 was only built for .NET Standard 2.1 (.NET Core only), but EF Core 3.1 was then built to be supported on .NET Standard 2.0 (.NET Framework 4.6.1+).

You guys' documentation claims to support EF Core 3.1, but we are facing some odd dependency-graph issues with your NuGet packages, when we are on .NET Framework 4.7.2, using EF Core 3.1 and trying to use your latest dotConnect for Oracle NuGet packages.

In particular, your Devart.Data.Oracle.EFCore version 9.12.1064 (currently latest version on .NET Standard 2.0) has a .NET Standard 2.0 constraint on it that states:
Microsoft.EntityFrameworkCore.Relational (>= 2.2.6 && < 3.0.0)

To us, this doesn't make very much sense, since presumably when using the main package of Microsoft.EntityFrameworkCore 3.1.3 (currently latest supported version according to the dotConnect for Oracle History changelog), the ".Relational" package is enforced to be the same version.

Is it the case that we should be trying to use Microsoft.EntityFrameworkCore 3.1.3 (whatever is supported according to your change logs) but keep the ".Relational" package on the 2.2.6 version? It seems a bit weird at the very least, and we would fear the occurrence of bugs as a result of the version discrepancy, especially when it's a different major version as well.

We figured that perhaps the issue was that you only support EF Core 3.1 on .NET Standard 2.1 (even though it supports .NET Standard 2.0), but at least this page here does not seem to suggest that there are any such constraints: https://blog.devart.com/entity-framewor ... iders.html

Are we misunderstanding or missing something obvious here? :)

Shalex
Site Admin
Posts: 9020
Joined: Thu 14 Aug 2008 12:44

Re: Support for EF Core 3.1 on .NET Standard 2.0

Post by Shalex » Mon 14 Sep 2020 14:29

KRU wrote:
Thu 10 Sep 2020 14:16
we are on .NET Framework 4.7.2, using EF Core 3.1 and trying to use your latest dotConnect for Oracle NuGet packages.
KRU wrote:
Thu 10 Sep 2020 14:16
We figured that perhaps the issue was that you only support EF Core 3.1 on .NET Standard 2.1 (even though it supports .NET Standard 2.0), but at least this page here does not seem to suggest that there are any such constraints: https://blog.devart.com/entity-framewor ... iders.html
The page says:
"So finally we also can support Entity Framework Core 3 for Full .NET Framework too, and we have added this support to all of our ADO.NET providers for cloud apps and for major databases.
All dotConnect providers with ORM support now include a new Devart.Data.<provider>.Entity.EFCore.dll assembly for Entity Framework Core 3.1 support on Full .NET Framework. You can find it in the \Entity\EFCore3 subfolder of the provider installation folder."

By default, the provider installation folder is "C:\Program Files (x86)\Devart\dotConnect\Oracle\".

The tutorials for full .NET Framework:
* https://www.devart.com/dotconnect/oracl ... FCore.html
* https://www.devart.com/dotconnect/oracl ... First.html

KRU
Posts: 5
Joined: Tue 08 Oct 2019 11:51

Re: Support for EF Core 3.1 on .NET Standard 2.0

Post by KRU » Wed 16 Sep 2020 06:13

Thank you for your response :)

I see that you mention that DLLs are now included on install of the Devart dotConnect for Oracle product to support EF Core 3.1 for .NET Framework, but perhaps I should clarify that we are looking to use the NuGet package approach of using Devart, and then supplying license information via the "LicenseKey" parameter on our connection-strings.

It is when trying to set up the EF Core + Devart NuGet packages that I experienced strange version-restrictions, and which resulted in this post.

We want to use the NuGet packages instead of embedding the DLLs in our apps, in order to avoid depending on having Devart installed on build agents, etc.

Thank you for any further inputs :)

Post Reply