Entity Framework Classic - Support

[JonathanMagnan]

Hello Scott,

Would you be interested to add support to Entity Framework Classic: https://entityframework-classic.net/

EF Classic is basically an Entity Framework 6 fork with performance improvement, new features, and .NET Core support.

If you want, we could create a pull on our side.

Best Regards,

Jonathan

[MikeAlhayek]

Agreed! This would be an amazing addition.

[StefH]

And which version do you want to support? Community, paid or both?

[JonathanMagnan]

Hello @StefH ,

Supporting one automatically support the other. They use the same name/signing key.

For example: https://www.nuget.org/packages/Z.EntityFramework.Plus.QueryIncludeFilter.EFClassic/
support both. This is probably not the best practices but by ommiting to add the dependencies to EF Classic in the Package, people can use the same QueryIncludeFilter package with EF Classic Community and Entreperise version.

I recommand you to use the Z.EntityFramework.Classic version in your reference. The Community package might be eventually be removed and be available in the main package instead if we feel that having two packages become a bad idea.

[StefH]

I've create a preview version, can you please try this one?
https://www.myget.org/feed/linqkit/package/nuget/LinqKit.Z.EntityFramework.Classic

[JonathanMagnan]

Hello @StefH ,

We made some test under .NET45 and .NET Core and everything we tested worked.

Is there something special you would like we test more? Is adding the support for EF Classic was a simple as changing the reference or something else had to be modified for our library?

On the package, I see there are some dependencies for EF Classic. Even if it depends on our package, I believe the package should not have any dependencies as long as we have 2 packages otherwise, for people that have EF Classic (Community), it might download the newest version for EF Classic (Enterprise) which is probably not what they want. It was perhaps a bad idea for third-party libraries on our side creating 2 packages ;)

You obviously know more LinqKit as ourselves, do you feel we should instead add a fake dependencies on LinqKit in our NuGet package to force people to add it in their project? So by default, when installing EF Classic, LinqKit will be automatically installed or you believe that would be a bad idea?

[StefH]

Some remarks:

1] If you don't need Include(...) and Async support, you should be able to just use the LinqKit.Core NuGet package. No need for me to update that package. Did you also test this one?

2] If you need Async support (IDbAsyncEnumerator) or Include(...) then you need to use a EF specific NuGet, that's the reason these project exists: LinqKit.EntityFramework and LinqKit.Microsoft.EntityFrameworkCore and LinqKit.Z.EntityFramework.Classic.
So if you could test specifically this functionality, that would be great. See DbAsyncTests.cs in the unittest-projects how this can be done.

I hope this explains.

3] A side question: did you also try to use Z.EntityFramework.Classic with https://github.com/StefH/System.Linq.Dynamic.Core ?

`

[JonathanMagnan]

Hello @StefH ,

LinqKit.Z.EntityFramework.Classic

We need the option 2. People expect to upgrade from EF6 to EF Classic and have everything working as it was in EF6. So something will be missed with option 1.

I have made a few tests and everything is working fine with async.

The person that requested us the support for LinqKit is currently testing it in his project, so I will try get his feedback this week.

System.Linq.Dynamic.Core

We tested System.Linq.Dynamic.Core and it already works great :)

However, we already have a free features for LINQ dynamic: https://entityframework-classic.net/linq-dynamic

Our version use C# syntax (it uses our library: https://eval-expression.net/)

So we don't have to use some fake syntax such as:

var customer2 = context.Customers.Select("new(ColumnInt as Name, ColumnString)").ToListAsync().Result;

You can use real C# syntax

var customer3 = context.Customers.SelectDynamic(x => "new { Name = x.ColumnInt, x.ColumnString }").ToListAsync().Result;

[StefH]

OK, I'll wait on the test results, and when all is fine, I can release a NuGet.

@Thorium and @scottksmith95
But I still thinking on which version to use, should I use version 1.0.0 for this new NuGet or use the current 1.1.15 or upgrade all to 1.1.16 to keep all versions aligned.

[Thorium]

I vote for keeping version numbers aligned.

[JonathanMagnan]

I agree with Thorium. Version aligned is the way to go.

Thank a lot btw for the fast support ;)

[JonathanMagnan]

Hello @StefH ,

I got the confirmation that everything worked like a charm also on his side. I believe at this point, it's safe to release a stable version whenever you have time.

[MikeAlhayek]

I also tested it and it seems to be all good! Great addition to this awesome package

[StefH]

New official NuGet is uploaded and will be visible in some time.

[JonathanMagnan]

Great,

Thank a lot ;)