DbContext: Throw on AddDbContext with options lambda when context has no options ctor

[anpete]

Right now we seem to silently ignore the options lambda. This bug is about whether we should throw or warn.

[ajcvickers]

We discussed this in the past and decided against it because we would have to replicate the logic in D.I. to determine if a constructor that takes the options would be used.

Even if we did that, we don't know that the context is not depending on something else that it gets the options from. Could be using service locator, or just have another service that depends on the options.

So to be sure we are not throwing for correct code we basically have to replicate a lot of the D,I, resolution (or somehow use D.I. to do it without actually resolving).

Or we can be okay with throwing when there is no actual issue. We decided against this when we discussed this before.

[anpete]

Makes sense. Maybe just something simple to catch a common case? I.e. when I hit this, both times my context had a single default ctor.

[ajcvickers]

Yeah, if the context only has a parameterless constructor, then I can't think of a way that AddDbContext would work correctly. So might be okay to throw then.

However, I would still consider this a breaking change because people do a lot of stuff that they don't need to do when it comes to D.I., presumably because its hard to understand how it works. I have seen several situations where code is using AddDbContext and has a parameterless constructor and the application works just fine because the context options set in AddDbContext are not actually used at all.