Inherit IdentityDbContext or any other custom DbContext

[mciprijanovic]

Hi, just a short question. Is it now possible or will be supported to somehow set custom DbContext to be inherited instead of DbContext class itself on code generation?
Example: since dbcontext file is autogenerated it will be rewritten each time something is changed in designer, and example where mentioned feature is needed is when using Microsoft Identity. In order to use Identity framework, application db context should be inherited from IdentityDbContext which itself inherits DbContext.

Thanks.

[msawczyn]

That's a feature that's on the drawing board right now. It turns out to be ... complicated. It's quite easy to simply change the inheritance chain for the generated DbContext, since IdentityDbContext is a known (and supported) thing. But in order to be really useful, the tool should also start with the appropriate classes already in place. After all, it is there to make life easier and the code predictable, right? And the design pattern for all that needs to be easy to follow and well documented, so that folks can extend the pattern to other specialized DbContext implementations, in addition to IdentityDbContext.

That means a few restrictions and validations have to be in place that turn out to be nontrivial. There is a branch that I started and haven't gotten back to in quite a while, but do plan to return to after the 2.0 release. That's going to happen in the pretty near future. The person that put in the enhancement request all those many months ago also implemented an example project that points out one way the output could look. I still have that code and plan to re-review it when I get back to that enhancement. (Or, of course, someone else can pick up on it and help carry it forward [hint, hint] since it is open source!)

That being said, for a short-term, down-and-dirty approach you can always copy the appropriate .ttinclude file (either EF6Designer.ttinclude or EFCoreDesigner.ttinclude, depending on the flavor of Entity Framework you're working with) and add it to your project. Local .ttinclude files override the installed files, so you can change the code that's being output and implement an alternate inheritance chain. There's instructions on that in the documentation. Those two files are the most interesting since they're involved in the DbContext output ... there really isn't anything that changes in the output code for the entities (that's driven by EFDesigner.ttinclude, which is common to both EF flavors).

Hope that answers the question. :-)

-- Michael

[mciprijanovic]

I managed to make this work according to your instructions. Things I did:

1. Changed EFCoreDesigner.ttincludein the manner that generated DbContext inherits IdentityDbContext
2. Changed EFDesigner.ttinclude in the manner that my Account class inherits IdentityUser

After this, other entities in schema are simply bound to Account, and all is OK. If there was the possibility to set base DbContext and possibility to set base class for entities in the free form (like for custom attributes), out of the list of already created entities in the designer, need for changing templates would not exist. But, I believe that releasing mentioned constraints would create a mess on some other side.

[msawczyn]

In 2.0 we'll have the ability to change the base class of the context to something other than DbContext, but full IdentityDbContext support won't yet be there in the way I want it to be.

A step forward, though! :-)