Turn "More than twenty 'IServiceProvider'..." warning to error by default

[ajcvickers]

Since the application is almost certainly doing something wrong. Note this is a breaking changes and so probably can't happen until 3.0.

[ajcvickers]

Marking for re-triage. Our tests are perhaps the one place where having more than twenty internal service providers is expected, since we test all the uncommon situations that require new service providers. We need to have a plan for our tests before we make a change like this.

[ajcvickers]

Triage: Try not using the internal cache in our tests...

[ajcvickers]

Further food for thought on this one. The Identity tests failed and the root cause is interesting because it doesn't directly involve calling UseLoggerFactory or anything else "obviously wrong". Instead, if you setup ASP.NET tests to each run with its own isolated IServiceProvider, then a simple call to AddDbContext when setting up this service provider will result in a different ILoggerFactory and IMemoryCache being used for each test, which results in a new internal service provider per test. Hence boom.

[divega]

@ajcvickers do we keep track of the application service provider? Would it be possible to throw only when too many internal service providers have been created for the same application service provider?

[ajcvickers]

@divega Yeah, it would be. However, I'm not sure that's the right thing to do, because the case, as hit by the Identity tests, is pathological. Consider, each test creates and throws away an app service provider, but each time it does this it adds to the collection of internal service providers, which grows without bounds. So, it would be "really great"(TM) if we could find some way to prevent this. I've been trying to figure out if we can somehow know that the root of the app service provider has been disposed, and use that to flush the entity from our cache.

[divega]

@ajcvickers I think I understand. I believe the detail that I was missing is precisely that the collection of internal service providers isn't really rooted on the application service provider.

[divega]

I've been trying to figure out if we can somehow know that the root of the app service provider has been disposed, and use that to flush the entity from our cache.

@ajcvickers could we register a disposable service to keep track of the lifetime of the container?

[ajcvickers]

@divega That's along the lines I was thinking. Problem is, the root IServiceProvider is usually not disposed.

[divega]

Maybe that could be considered a bug in the tests 😄

[ajcvickers]

@divega I thought about that too, but I don't think it really holds.

[divega]

@ajcvickers FWIW, I believe during the triage this discussion I was confused about what you were proposing. Now I think you are saying make logger factory scoped to the DbContext and stop taking an external memory cache. Is this correct?

[ajcvickers]

@divega Yes.