[Nightly] Base DbContext prefers parameterless constructor when injected

[Grinderofl]

As a result of #4750

services.AddEntityFrameworkInMemoryDatabase()
                .AddDbContext<DbContext>(
                    (p, x) => x.UseInMemoryDatabase().UseInternalServiceProvider(p));

var context = provider.GetService<DbContext>(); 
// context == null 

It's only if I subclass and add a constructor that takes DbContextOptions as dependency and passes it into base that context is not null.

This is not consistent with previous alpha-beta-rc1-rc2uptolastweek behaviour, as well as Entity Framework 6's behaviour. As it's possible - using IModelCustomizer - to alter ModelBuilder from outside DbContext's OnModelBuilding method, it's used to be possible to have no application-specific DbContexts. In fact, to use Identity as anonymous, all one had to do previously is add IdentityContext! Not being able to do this violates L of SOLID.

This may potentially be relevant for DependencyInjection project.

[Grinderofl]

Can be provisionally solved by doing

services.Replace(
                ServiceDescriptor.Scoped<DbContext>(provider => new DbContext(provider.GetService<DbContextOptions>())));

[Grinderofl]

This is still an issue, DbContext should default to parametered constructor.

[ajcvickers]

This was not caused by using the wrong constructor, but rather by conflicting registrations of DbContext as required by EF and the application. The internal EF registration was running first, followed by the one in AddDbContext, but since this one was using TryAdd it effectively did nothing. The reason the workaround worked is because it was forcing a new registration.

The issue would not be hit if the app service provider was not also used as EF's internal service provider, and if AddEntityFrameworkInMemoryDatabase was therefore never called by the application. This is what will be in the ASP.NET templates going forward. However, PR #4883 also fixes the issue for cases like this where the app wishes to use the same service provider for EF internal services.

Note that the built-in D.I. container will select the DbContextOptions constructor. However, it is still possible that some other D.I. container will select the parameterless constructor.