I am working on an AspNetCore 2.1 WebApi. I am using Microsoft.Extensions.DependencyInjection, AspNetCore.Identity, and EntityFrameworkCore.
In my DI registrations, I am calling:
services.AddDbContext<IMyDbContext, MyDbContext>();
Good, right? Pass around the contract. But then I hit an exception that the Identity Manager classes (UserManager, RoleManager, etc.) cannot be respolved in the Dependency Injection container because the Identity Stores they use (UserStore, RoleStore, etc.) cannot resolve their DI parameter (MyDbContext).
It all points to this line when setting up Identity:
builder.AddEntityFrameworkStores<MyDbContext>();
... which is puking since the Identity Stores are looking for the concrete context and it is not registered with DI. The extension is expecting a class that it can resolve down to DbContext - and I cannot add an implicit operator to the interface IMyDbContext to give it an implicit cast the DI extension method could use.
All this has me performing a rather ugly DI registration:
services
.AddDbContext<IMyDbContext, MyDbContext>()
.AddDbContext<MyDbContext>();
- a DI registration that may cause other issues (thread safety, transactional) downstream that I haven't encountered yet.
My guess is that I could clean up the DI registration by rolling my own IServiceCollection extension and/or custom Identity Stores - which really seems like overkill here as I otherwise have no need to go beyond the default built-in Identity Stores.
I also don't really want to remove the <interface, concrete> context registration as that will trickle down to all my constructor injections, and just seems wrong.
Has anybody tackled this already and found a work-around? Or can anybody at least confirm/deny that the double (interface && concrete) context registration in the DI will not cause other issues?
Thanks in advance!