Verifying your DI Container

[giscus[bot]]

Verifying your DI Container

Microsoft's integrated dependency injection (short DI) container is very powerful, but there are also certain pitfalls. In this article, I will show you what some of the pitfalls are and how you can verify them.

https://steven-giesel.com/blogPost/ce948083-974a-4c16-877f-246b8909fa6d

[mehdihadeli]

Hey Steven,
Thanks for these useful tips :)
Something that I want to mention here:

• .Net handles CheckForCaptiveDependencies internally with setting ValidateScopes to true, and it is true by default in Development environment, and maybe we don't need CheckForCaptiveDependencies:

builder.Host.UseDefaultServiceProvider(
    (context, options) =>
    {
        var isDevMode =
            context.HostingEnvironment.IsDevelopment()
            || context.HostingEnvironment.IsEnvironment("test")
            || context.HostingEnvironment.IsStaging();

        // CreateDefaultBuilder and WebApplicationBuilder in minimal apis sets `ServiceProviderOptions.ValidateScopes` and `ServiceProviderOptions.ValidateOnBuild` to true if the app's environment is Development.
        options.ValidateScopes = isDevMode; 
        options.ValidateOnBuild = isDevMode; 
    }

• When we call CheckServicesCanBeResolved on all services we get some unwanted exceptions that we are not responsible for them, for example when we use third party libs, just try your example with a dotnet new webapi template, and you will get some exceptions, so I changed your code like this for handling just my app services for dependency check and it works without error:

    public static void ValidateDependencies(
        this IServiceProvider rootServiceProvider,
        IServiceCollection services,
        params Assembly[] assembliesToScan
    )
    {
        var scanAssemblies = assembliesToScan.Any() ? assembliesToScan : new[] { Assembly.GetExecutingAssembly(), };
        var exceptions = new List<string>();

        // for resolving scoped based dependencies without errors
        using var scope = rootServiceProvider.CreateScope();
        var sp = scope.ServiceProvider;

        foreach (var serviceDescriptor in services)
        {
            try
            {
                var serviceType = serviceDescriptor.ServiceType;
                if (scanAssemblies.Contains(serviceType.Assembly))
                    sp.GetRequiredService(serviceType);
            }
            catch (Exception e)
            {
                exceptions.Add($"Unable to resolve '{serviceDescriptor.ServiceType.FullName}', detail: {e.Message}");
            }
        }

        if (exceptions.Any())
        {
            throw new Exception(string.Join("\n", exceptions));
        }
    }

• Also, it is good to mention that Net internally does some validation for dependencies by default in Development mode, but because of some of its limitations, like the injection of  IServiceProvider, we can use this approach in combination. Here is a good article about that.

[linkdotnet]

Hey @mehdihadeli,

very nice! Yes afterward U was also aware that ASP.NET does some checks on its own (at least the captive dep check).

for example when we use third party libs, just try your example with a dotnet new webapi template, and you will get some exceptions

I like that approach - but maybe for clarification why do we receive some "expected" exceptions in dotnet new webapi. For sure the exception check should be on type InvalidOperationException (I will update this in the article), but I wouldn't expect any missing services by default. Do you have more information here?

[mehdihadeli]

Steven, Also I've changed this part in ValidateDependencies, for resolving scoped based dependency like DBContext:

    // for resolving scoped based dependencies without errors
    using var scope = rootServiceProvider.CreateScope();
    var sp = scope.ServiceProvider;

about unexpected errors when we do dependency checks on all services let me create a sample for you, maybe it is my mistake :D

[mehdihadeli]

I prepare this one as a sample, it is an empty webapi template, and I expect it runs without errors
https://github.com/mehdihadeli/verify-dependencies

[linkdotnet]

Steven, Also I've changed this part in ValidateDependencies, for resolving scoped based dependency like DBContext:

    // for resolving scoped based dependencies without errors
    using var scope = rootServiceProvider.CreateScope();
    var sp = scope.ServiceProvider;

about unexpected errors when we do dependency checks on all services let me create a sample for you, maybe it is my mistake :D

Oh yeah that is a really fair point. At least in an ASP.NET Core context, my suggestion would fail "twice" which is not optimal. So your way of handling the situation is better. Thanks for the initiative!

[mehdihadeli]

You're welcome, my friend :) This topic is really important and unfortunately there is no good docs about that. Thanks for writing this blog ;)

[HaimAbeles]

Awesome blog, thanks!