How do I validate the DI container in ASP.NET Core?

Question

In my Startup class I use the ConfigureServices(IServiceCollection services) method to set up my service container, using the built-in DI container from Microsoft.Extensions.DependencyInjection.

I want to validate the dependency graph in an unit test to check that all of the services can be constructed, so that I can fix any services missing during unit testing instead of having the app crash at runtime. In previous projects I've used Simple Injector, which has a .Verify() method for the container. But I haven't been able to find anything similar for ASP.NET Core.

Is there any built-in (or at least recommended) way of verifying that the entire dependency graph can be constructed?

(The dumbest way I can think of is something like this, but it will still fail because of the open generics that are injected by the framework itself):

startup.ConfigureServices(serviceCollection); var provider = serviceCollection.BuildServiceProvider(); foreach (var serviceDescriptor in serviceCollection) {     provider.GetService(serviceDescriptor.ServiceType); } 

Answer 1

A built-in DI container validation was added in ASP.NET Core 3 and it is enabled only in the Development environment by default. If something is missing, the container throws a fatal exception on startup.

Keep in mind that controllers aren't created in the DI container by default, so a typical web app won't get much from this check until the controllers are registered in the DI:

public void ConfigureServices(IServiceCollection services) {     services.AddControllers()         .AddControllersAsServices(); } 

To disable/customize the validation, add a IHostBuilder.UseDefaultServiceProvider call:

public class Program {     public static IHostBuilder CreateHostBuilder(string[] args) =>         Host.CreateDefaultBuilder(args)             //...             .UseDefaultServiceProvider((context, options) =>             {                 options.ValidateOnBuild = false;             }); 

This validation feature has several limitations, read more here: https://andrewlock.net/new-in-asp-net-core-3-service-provider-validation/

Answer 2

Actually, I just used the example from your question with a few modifications and it worked pretty well for me. The theory behind filtering by classes in my namespace is that those will end up asking for everything else I care about.

My test looked a lot like this:

[Test or Fact or Whatever] public void AllDependenciesPresentAndAccountedFor() {     // Arrange     var startup = new Startup();      // Act     startup.ConfigureServices(serviceCollection);      // Assert     var exceptions = new List<InvalidOperationException>();     var provider = serviceCollection.BuildServiceProvider();     foreach (var serviceDescriptor in services)     {         var serviceType = serviceDescriptor.ServiceType;         if (serviceType.Namespace.StartsWith("my.namespace.here"))         {             try             {                 provider.GetService(serviceType);             }             catch (InvalidOperationException e)             {                 exceptions.Add(e);             }         }     }      if (exceptions.Any())     {         throw new AggregateException("Some services are missing", exceptions);     } }