Fine grained nuget packages about entityframework.commontools HOT 2 CLOSED

Hm... Now we have two different packages: EntityFrameworkCore.CommonTools for EF Core and EntityFramework.CommonTools for EF6. If I split them by functionality, I would get 12 separate packages:

• EntityFramework.CommonTools.Core
• EntityFramework.CommonTools.Auditing
• EntityFramework.CommonTools.Concurrency
• EntityFramework.CommonTools.Json
• EntityFramework.CommonTools.TransactionLog
• EntityFramework.CommonTools.Specification
• and 6 EntityFrameworkCore.CommonTools.* packages

This is very hard to maintain. And also it would not solve your problem:
EntityFramework.CommonTools.Specification should depends on EntityFramework.CommonTools.Core which depends on EntityFramework.

But I can extract a single package which not depends on EntityFramework. It would contain:

• IQueryable Extensions
• JSON Complex Types
• Specification Pattern

The only caveat is that with such package we could not use EF-dependent IQueryable extensions like .ToListAsync():

IQueryable<User> usersQuery = ...;

var spec = new FriendSpecification();

IQueryable<User> friendsQuery =  usersQuery 
    .AsVisitable(new SpecificationExpander())
    .Where(u => u.Firends.Any(spec.ToExpression()));

friendsQuery.ToList(); // Ok
friendsQuery.ToListAsync(); // should throw Exception

from entityframework.commontools.

Didn't realize that Specification would depend on Core and EF.
Also didn't think about giving support to both EF 6 and EF Core that is much more relevant than extracting Specification (I was just thinking about my problem :s ).
I now understand your decision of packing everything in the same packages.
It would be nice to have your Specification implementation in a standalone package, but I now understand that the advantages of this implementation come from the integration with EF.
I will still use this implementation whenever I will also need EF.
Thanks

from entityframework.commontools.