Add ability to enforce stricter "Singleton" rules in the MS DI extensions

[jochenz]

The basic issue is this:

// written by first developer
services.AddSingleton<TInterface, TImpl1>();
// written by second developer, somewhere deep down in an assembly
services.AddSingleton<TInterface, TImpl2>();

The IServiceProvider will return a TImpl2 on a request for a TInterface. Developer 1 will be really surprised about this and developer 2 will probably not realize that he has overruled the intentions of developer 1.

Similarly, two invocations of services.AddSingleton<X>() will result in two instances of X in the service provider. This is also unexpected behaviour for most developers.

The advice seems to be to use TryAddSingleton, but this has multiple shortcomings:

• it's a silent failure
  • there is no indication of success
  • if you want to throw an exception on failure, you need to inspect the state of the IServiceCollection (i.e. inspect all ServiceDescriptors)
• it depends on the order of execution of two invocations which one wins (a simple swap of some lines of code might provide suprising results)
• it requires a developer's attention to detail to detect potential conflicts (if at all possible to detect that from his perspective on the code)

So, I'm looking for possibilities to enforce stricter rules on a subset of types (e.g. all types in my own assemblies). The type filter is obviously required for backwards compatibility.

Having completely overlooked the discussions tab, I already created an API proposal...

Basically, it would be good to be able to enforce strict singleton rules by writing something like this:

namespace Demo;

// predicate to check if type is in demo assembly
bool InDemoAssembly(Type type) => type.Namespace?.StartsWith("Demo") ?? false;

// enforce strict singletons for the demo assembly
services.EnforceStrictSingletonsWhen(InDemoAssembly);

services.AddSingleton<X>();
// boom! throws exception, not allowed, no more silent unexpected behaviour
services.AddSingleton<X>();

class X {}

Given that in many cases we are using the generic host, our only real interaction with DI configuration is adding service to the IServiceCollection. With the generic host, developers are not involved in the creation of the IServiceProvider and also don't have any access to it, so I think this API should be available on the IServiceCollection.

[jochenz]

Of course, we can write our own overload which enforces strict singletons, but this requires developer attention or code analyzers. It is not "inherently safe" for singleton type registrations. Here's the sample code with demo tests:

    [Fact]
    public void StrictSingletonForConcreteType()
    {
        IServiceCollection services = new ServiceCollection();

        Action addStrictSingleton = () => services.AddStrictSingleton<X>();

        addStrictSingleton();
        addStrictSingleton.Should().Throw<InvalidOperationException>();
    }

    [Fact]
    public void StrictSingletonForTypeWithInterface()
    {
        IServiceCollection services = new ServiceCollection();

        Action addStrictSingleton = () => services.AddStrictSingleton<IMyInterface, Implementation>();

        addStrictSingleton();
        addStrictSingleton.Should().Throw<InvalidOperationException>();
    }
    
public static class SingletonExtensions
{
    public static IServiceCollection AddStrictSingleton<T>(this IServiceCollection services) 
        where T : class
    {
        return services
            .ThrowIfTypeAlreadyRegistered<T>(
                $"Cannot add {typeof(T).Name} as a singleton, because it was already registered in the service collection.")
            .AddSingleton<T>();
    }

    public static IServiceCollection AddStrictSingleton<TInterface, TImplementation>(this IServiceCollection services) 
        where TInterface : class 
        where TImplementation : class, TInterface
    {
        return services
            .ThrowIfTypeAlreadyRegistered<TInterface>(
                $"Cannot add {typeof(TImplementation).Name} as a singleton {typeof(TInterface).Name}, because {typeof(TInterface).Name} was already registered in the service collection.")
            .AddSingleton<TInterface, TImplementation>();
    }

    private static IServiceCollection ThrowIfTypeAlreadyRegistered<T>(this IServiceCollection services, string message)
    {
        if (services.HasRegistrationFor<T>())
            throw new InvalidOperationException(message);

        return services;
    }

    private static bool HasRegistrationFor<T>(this IServiceCollection services)
    {
        return services.Any(sd => sd.ServiceType == typeof(T));
    }
}    

[davidfowl]

This feels like something that could be an opt in validation. I'm guess that it would blow up for most application though. This needs to be controlled on a per type basis. This mechanism is used all over to replace implementations.

[jochenz]

Indeed: the sample code shows how you provide a required type filter.

// predicate to limit the validation to your scope of choice (based on registered `Type`)
bool InDemoAssembly(Type type) => type.Namespace?.StartsWith("Demo") ?? false;

// enforce strict singletons on your scope
services.EnforceStrictSingletonsWhen(InDemoAssembly);

[jochenz]

But the whole point is that you do want to enforce the strict rule on an entire scope of code (e.g. all code you maintain yourself), so developers don't continuously have to think about the ambiguous current interpretation of "singleton service".

If you'd want it truly on a type-per-type basis, then you could use the AddStrictSingleton extension method, suggested in the comment above.

[En3Tho]

I resorted to my own extensions too. Like TryAddXxxOrFail. The downside is that these have to scan services all over again and again if the specified TService is registered.

This only works if you're in total control control of your code but still want to be sure. Working in the team does not give you any guarantees.

I guess something like OnServiceProviderBuilt event could do the thing? E.g. you could register validation, initialization, etc there