Running FirstOrDefaultAsync with AsExpandable gives the error

[atul221282]

Hi Guys I am running following code and gives an error

static Expression<Func<string, bool>> condition = a => a != null;

var expanded = condition.Expand();
var quee = this.riskRepository.Query().AsExpandable().Where(x => expanded.Invoke(x.PurchaseNumber) && x.AMD_Seq_Num == seqNum).FirstOrDefaultAsync();

The provider for the source IQueryable doesn't implement IDbAsyncQueryProvider. Only providers that implement IDbAsyncQueryProvider can be used for Entity Framework asynchronous operations. For more details see http://go.microsoft.com/fwlink/?LinkId=287068.

Whereas this works fine Note using non async method workds fine

var expanded = condition.Expand();
var quee = this.riskRepository.Query().AsExpandable().Where(x => expanded.Invoke(x.PurchaseNumber) && x.AMD_Seq_Num == seqNum).FirstOrDefault();

[StefH]

You need this nuget :
http://www.nuget.org/packages/LinqKit.EntityFramework/ if you use EF 6.x

[Thorium]

The error could be to download the NuGet. Could we do that?

[StefH]

@Thorium Sorry ?

[Thorium]

By the Nuget package download statics we can expect that only 10% of the users use these new versions where the async is broken. So this issue will be hit about 50 000 times by different users in the future. So we could improve the user experience of this non-ef-version by:

a) loading the EF reference by reflection if the dll is present in the current folder. Then it could work?
b) or at least improve the error message to download the link.
c) or rename this current to LinqKit.Core and the old back to LinqKit (but LinqKit.Core is taken?)

[StefH]

I see your point.

The problem is that there are two version from EntityFramework : the old one, and the .Net Core one. That's the reason I've created three separate projects.

a) I'm not sure if that's possible because you don't know if you are using EntityFramework or Microsoft.EntityFrameworkCore
b) I'm not sure if we can fix this / hook into that exception.
c) That one is indeed taken by someone else. We could ask him.
d) If we want to please the older users and not introduce any breaking changes, then we must change the projects as follows:

• LinqKit is the EntityFramework version which has a hard dependency to EntityFramework 6.x
• LinqKit.EntityFramework is the same as LinqKit, but we keep it on nuget for compatibility ?
• LinqKit.Microsoft.EntityFrameworkCore could stay the same. (Has a hard dependency on .Net Core version : Microsoft.EntityFrameworkCore)
• LinqKit.Core or LinqKit.Barebone or Linqkit.Bare or Linqkit.NoDeps is the version without any dependencies to any EntityFramework version

[StefH]

I replied to @dopare to also add me as an owner to NuGet.

@Thorium What do you think the new projects should be named ?

[Thorium]

I still don't know if this is a problem or not, but I'd kind of like the non-ef-version to be named LinqKit.Core as many other .NET projects use this Core-naming to be not-the-dotnet-core but the-basic-core-functionality library (castle.core, system.reactive.core, sqlite.core, ...).

[StefH]

Proposals:

Old package                           | New package                           | Version   | Info    | Dependency
--------------------------------------+---------------------------------------+-----------+---------+-------------
LinqKit.EntityFramework               | LinqKit                               | 1.1.8.0   | Change  | EntityFramework 6.x
LinqKit.Microsoft.EntityFrameworkCore | LinqKit.Microsoft.EntityFrameworkCore | 1.0.5.0   | Keep    | Microsoft.EntityFrameworkCore
LinqKit                               | LinqKit.Core                          | 1.1.8.0   | Change  | No dependencies
LinqKit.EntityFramework               | LinqKit.EntityFramework               | 1.0.4.0   | Keep    | EntityFramework 6.x

[Thorium]

Sounds good. I would vote for unlisting LinqKit.EntityFramework from NuGet when this is done.

What is your opinion on EF6 future anyways? It seems that "EntityFramework" is the 6.1.3 and EF7 won't be "EntityFramework" but something else ("Microsoft.EntityFrameworkCore.SqlServer") and the Nuget id of "EntityFramework" will stay in that code base.

Maybe I would drop "Microsoft" from "LinqKit.Microsoft.EntityFrameworkCore" because this is not a Microsoft maintained project.

[StefH]

Hi @Thorium,

I've another (radical) proposal for fixing compatibility issues as discussed in this thread and #14.

Create a new version from LinqKit which throws an exception on all extension methods. The exception message should be like:

This NuGet package is obsolete !

• Use LinqKit.Core if you want to use the functionality without any reference to EntityFramework.
• Use the LinqKit.EntityFramework if you are using this library together with EntityFramework version 6.3.
• Use the LinqKit.Microsoft.EntityFrameworkCore if you are using this library together with Microsoft.EntityFrameworkCore version 1.x.x.

At the time, post a new LinqKit.Core to NuGet which replaces the functionality from LinqKit. And maybe delete all other versions from LinqKit except the last one?

This proposal is in line with some decisions made by Microsoft : https://github.com/dotnet/standard/blob/master/docs/faq.md#will-there-be-tooling-to-highlight-apis-that-dont-work-everywhere

I'll make a PR so you can review code changes.

[StefH]

Fixed by #52

Issue will be closed.

@atul221282 use latest nuget pacakges for testing.

[atul221282]

Ok guys I will give it a try