[API Proposal]: ServiceCollection support post service registration

[Li7ye]

Background and motivation

I'm a framework programmer. Usually, I often add extension method for IServiceCollection. But sometimes, my extension method is required to know IServiceCollection state.

For instance, services.AddUnitOfWork() need to know all DbContextOptions in services and update DbContextOptions. if services.AddUnitOfWork() is added after registration of all dbcontexts, it can work properly. Otherwise, can get side effect(unexpected behavior). Some users maybe call services.AddUnitOfWork before or between dbcontexts registration by accident, because AddUnitOfWork is built on IServiceCollection and there is no restriction.

// work properly
services.AddDbContext<DB1>();
services.AddDbContext<DB2>();
services.AddUnitOfWork();

// side effect
services.AddDbContext<DB1>();
services.AddUnitOfWork();
services.AddDbContext<DB2>();

// can't work
services.AddUnitOfWork();
services.AddDbContext<DB1>();
services.AddDbContext<DB2>();

API Proposal

I suggest has an interface can be invoked after all services registered but before build to provider.

public interface IPostServiceRegistration
{
      void AddService(IServiceCollection services);
}

API Usage

services.AddPostRegistration<MyPostRegistration>()

Hence services.AddUnitOfWork can use the new feature to register own services or add validation, and can be added out of order by user. User only know I need to call this method without other knowledge.

Alternative Designs

No response

Risks

No response

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-extensions-dependencyinjection
See info in area-owners.md if you want to be subscribed.

[colejohnson66]

This sounds like an abuse of the service locator?