Does not support Async operations with EF 6.1.1

[hazzik]

Does not support Async operations with EF 6.1.1

[JonPSmith]

Bit more information on this error:

If you follow the http://go.microsoft.com/fwlink/?LinkId=287068 link then it explains what is going on, i.e. EF v6 brought in a new Interface for Async. The interesting thing is the page also provides an idea of what is needed in a section on Unit Testing Async.

Now I'm willing to have a go at this as its a deal-breaker for my GenericServices library, which supports sync and async versions of all CRUD operations. The async/await feature introduced in .NET 4.5 and is very important.

Problem is, where do I start? Any advice gratefully received.

[hazzik]

The problem here that IDbAsyncQueryProvider / IDbAsyncEnumerable interfaces are defined in EF
assembly, and not in BCL

[hazzik]

It can be fixed with .NET 4.6 [AssemblyNeutral], but anyway it means
dropping support of .NET 4.5 and below. Or we higly tie it with EF. Both
are not an option.

[hazzik]

Another option: to have "DelegateDecompiler.EF" adapter.

[JonPSmith]

Hi @hazzik. Thanks for looking at that. I agree you don't want to be too tied to EF so an DelegateDecompiler.EF is a great idea. I am happy to look at this. From your research where should I look at inside DelegateDecompiler?

[daveaglick]

I just added another commit to my PR that should resolve this issue. See the PR comments for more details.

Of note - you will need to drop your test database if it's already been created because the namespace move for the EF test project results in different migration names. If you don't recreate the test database, EF will think it's missing migrations because it'll see the ones with the old namespace in their name,

[hazzik]

Fixed in #31

[hazzik]

Package is live https://www.nuget.org/packages/DelegateDecompiler.EntityFramework

[JonPSmith]

Hi @hazzik and @somedave,

Awesome. Just upgraded GenericServices to the new DelegateDecompiler.EntityFramework framework and async works. I also see from the generated documentation that it now supports all the various nullable tests, which is also great.

One question/comment: I could imagine a situation where you need both the DelegateDecompiler namespace and the DelegateDecompiler.EntityFramework, at which point you get an 'ambiguous reference' compile error. Dave did suggest another name, like DecompileEf or something. Is it a good idea to change things now before people start using it??