[API proposal] Help DI container release transient services

[rosebyte]

By the principles of IoC, classes should not own, or have any special knowledge of, their dependencies. Attempts to work around this tend to cause problems and usually result in questionable design.

Following this rule, containers must own instances from creation until disposal.

The container already knows when to dispose of most services: singletons are disposed at the end of the container’s lifetime, and scoped services at the end of the scope’s lifetime. The only unresolved case is transient services, as the container has no reliable signal indicating when they are no longer in use and can be released.

To provide this information to the provider, we would need to change how services are consumed, because the consumer is the one supplying (or not supplying) that information. Changing anything at registration time does not help, as the consumer has no visibility into it. For example, a service may register a transient dependency that it later consumes, but at the point of consumption it cannot know whether the registration was modified, or even whether the service is transient. That would violate the rule stated above.

API Proposal

To avoid breaking changes, this would require introducing a new interface to support the feature, together with an extension method on IServiceProvider that checks whether the provider implements the new interface.

public readonly struct Lease<T> : IDisposable
{
    public T Service { get; }
    public void Dispose() { throw null; }
}

public interface ILeaseServiceProvider
{
    Lease<T> LeaseService<T>();
}

public static class DependencyInjectionExtensions
{
    public static Lease<T> LeaseService<T>(this IServiceProvider provider)
    {
        if (provider is not ILeaseServiceProvider leaseProvider)
        {
            throw NotSupportedException ("The container doesn't support leases.")
        }

        return leaseProvider.LeaseService<T>();
    }
}

The mechanism should guarantee thread-unsafe idempotency on disposal, not using the service after disposal is called is on the consumer side as we can't guarantee it at all.

Leasing doesn't make much sense for dependency resolution as the end of life of the service is a natural end of life of the leased service too.

Alternatives

Of course, the most obvious alternative is to require users to use a custom factory (likely obtained from DI) to acquire instances they want to own and manage explicitly, especially when those instances are used heavily or in ways that put pressure on the container.

That said, an alternative to the API described above would be to use a class-based lease:

public class Lease<T> : IDisposable
{
    public T Service { get; }
    public void Dispose() { throw null; }
}

Using a class would guarantee synchronisation, as it is passed by reference. That would allow disposal idempotence to be enforced by the lease item itself.

Moreover, most allocation scenarios could be mitigated by making the lease class resettable and allowing users to optionally supply it. They have the necessary context and can guarantee the correctness of the control flow. Typical hot-path scenarios involving transient services are short-lived and well-encapsulated, so storing a lease instance in a thread-static variable would likely be sufficient in practice.

public interface ILeaseServiceProvider
{
    Lease<T> LeaseService<T>(Lease<T>? lease);
}   <>

public static class DependencyInjectionExtensions
{
    public static Lease<T> LeaseService<T>(this IServiceProvider provider, Lease<T>? lease) { throw null; }
}

Another consideration is whether the lease should implement IAsyncDisposable to handle services that implement this interface. I do not think it should, as disposing the lease merely informs the container that the service is no longer in use, which is not an asynchronous operation. How the service is ultimately disposed is a concern of the container, not of the lease itself. That said, I am open to discussion.

Non-viable alternatives

There are a couple of other alternatives I can see, with what seem to be straightforward reasons why they are not viable. That said, I might be wrong, and I am happy to discuss any of them:

1. Add the Lease class to DI as an open generic. However, since the mechanism would need to cooperate with the container’s internal workings, this approach would likely come with many caveats and edge cases. At a minimum, the container would need to inspect each service to determine whether it is of this type and handle it differently. Moreover, this could easily lead to complicated situations when multiple container backends are involved.
2. Instead of returning a type, add another method to ILeaseServiceProvider and let users simply return the service when it is no longer needed. The problem is that there would be nothing to anchor this to: the returned value would just be an instance. While it would at least originate from the provider, we would still need a way to identify what action to take with it. In addition, services are typically instantiated through scopes, and there is no guarantee that users would return the service to the correct scope. This would require an additional mechanism to synchronise scopes, which feels significantly more complex and risky.
3. Use WeakReference and let users stop using the service. This would require a handle to the weak reference, and each weak reference is itself a class, resulting in one or two additional allocations. More importantly, we would still need to keep a reference in order to dispose the instance, and relying on finalisers does not guarantee that they will run or that disposal will actually happen.

[dotnet-policy-service]

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

[bwood4]

Would the intended use of this ask for the container and call the method, or ask for a Lease directly? ie

// This
public class Consumer(IServiceProvider serviceProvider) {
    private readonly Lease<IService> service = serviceProvider.LeaseService<IService>();
}

// Or this
public class Consumer(Lease<IService> service) { }

I don't mind the first one because it makes it obvious that you are reaching into the IServiceProvider abstraction a bit. The second method starts to make me think that all services should be requested as Lease<TService> just to make sure you have no memory leaks, but that would not be desirable.

Another alternative I can think of is to introduce a service that can return the lifetime of an object:

public interface IServiceLifetimeProvider {
    // Nullable in case object is not registered. Could also be TryGetServiceLifetime and return a bool
    ServiceLifetime? GetServiceLifetime(object service);
}

public class Consumer {
    private readonly IService _service;
    public Consumer(IService service, IServiceLifetimeProvider lifetimeProvider) {
        _service = service;
        if (service is IDisposable && lifetimeProvider.GetServiceLifetime(service) is ServiceLifetime lifetime && lifetime == ServiceLifetime.Transient) {
            // We know we should dispose if service is IDisposable and has a transient lifetime
        }
    }
}

Similar to the first use of Lease<T>, this makes it clear we're reaching into the service provider farther than normal, but I think it would come with an even smaller API impact and be more flexible. It would just be registered as a standalone service when the provider is built (by default like the similar IServiceProviderIsService interface) and no need to add additional extension methods to IServiceProvider.

[rosebyte]

Well, the idea was that when a transient is used as a dependency, the DI container knows its lifetime and the lease is not needed at all. If the consumer is a singleton, it lives until the container is disposed. If the consumer is scoped or an unleased transient, it lives until the scope is disposed, and if the consumer is leased, it lives until the lease is disposed.

You’re right, I was trying to propose something that would not turn into a new ConfigureAwait(false) used “just to be sure” everywhere :-)

I have a couple of concerns with exposing service lifetimes. Primarily, it breaks the IoC rule that classes should not know details about their dependencies, which actually works very well at preventing strange designs and overly complicated code. Besides, simply knowing that a service is a disposable transient would not be sufficient, as the container owns the instance and has to track it. Even if the consumer disposes the instance, it would still remain uncollected until the scope or the entire container is disposed.

[KalleOlaviNiemitalo]

public readonly struct Lease<T> : IDisposable
{
    public T Service { get; }
    public void Dispose() { throw null; }
}

Please clarify what Dispose() is expected to do there.

• Does it cause subsequent public T Service { get; } to throw ObjectDisposedException?
• Does it dispose the T instance if that is disposable?
  • Does it dispose transient dependencies of T?
• Does it somehow notify the service container that implemented ILeaseServiceProvider? I don't see an API for that.

How would a third-party service container create an instance of Lease<T>? There is no constructor proposed that would let the container set the public T Service { get; } property.

[bwood4]

Well, the idea was that when a transient is used as a dependency, the DI container knows its lifetime and the lease is not needed at all. If the consumer is a singleton, it lives until the container is disposed. If the consumer is scoped or an unleased transient, it lives until the scope is disposed, and if the consumer is leased, it lives until the lease is disposed.

It's a little unclear to me who has the reference to the Lease here. I'd expect the consumer to have the lease of the service so that it could dispose of it when it's done, which indicates to the container that it can dispose of underlying resource when appropriate. Is that correct?

Primarily, it breaks the IoC rule that classes should not know details about their dependencies, which actually works very well at preventing strange designs and overly complicated code.

I think the only ways to not break that rule in any way are either

1. Have the container handle disposing of transient dependencies, preferably through some WeakReference mechanism (I'm not sure if this is possible/reliable as you mentioned in OP)
2. Require that consumers indicate to the container that they are done with their dependencies. This would have to be done for every dependency, which would be a big paradigm shift in DI

Otherwise classes have to know if their dependency is IDisposable and whether or not they should dispose of them (ie. whether they "own" them or not), which are details that they should not generally need to know.

The argument for a service to retrieve the lifetime of a dependency is acknowledging that option 1 isn't feasible, and option 2 is worse than special-casing a solution. Since transient, disposable dependencies are the only type of dependency that has this problem, I think having special knowledge to deal with that rare scenario is an OK solution.

It's also why I don't mind having to manually call LeaseService() on an IServiceProvider; requesting IServiceProvider as a dependency in the first place is a good indicator that you are trying to handle a special scenario (or possibly doing something you shouldn't be).

Besides, simply knowing that a service is a disposable transient would not be sufficient, as the container owns the instance and has to track it. Even if the consumer disposes the instance, it would still remain uncollected until the scope or the entire container is disposed.

This is true. The object would be disposed, but the container would still hold a reference to it unless the container used a WeakReference or did not track transients. If neither of those are an option, maybe tweaking it would work:

public interface IServiceLifetimeProvider
{
    // Now accepts a Type instead
    ServiceLifetime? GetServiceLifetime(Type serviceType);
}

public class Consumer()
{
    public Consumer(IServiceProvider serviceProvider, IServiceLifetimeProvider lifetimeProvider)
    {
        IService service;
        bool disposeService;
        // If IService is registered as scoped or singleton, then we just get the service and won't dispose of it when we're done
        if (lifetimeProvider.GetServiceLifetime(typeof(IService)) is ServiceLifetime.Scoped or ServiceLifetime.Singleton)
        {
            service = serviceProvider.GetService<IService>();
            disposeService = false;
        }
        // Otherwise we manually create a new one and know we need to dispose of it. In this case, the IoC container won't track the reference created
       else
       {
            service = ActivatorUtilities.CreateInstance<IService>(serviceProvider);
            disposeService = true;
       }
    }
}

I'd also note that IServiceProviderIsService already exists for the sole purpose of checking whether a type is registered with the IoC container. IServiceLifetimeProvider just takes that a step further to also indicate what the lifetime is.

[colejohnson66]

IMHO, a better name is "owned". Cribbing from Autofac, but the name conveys that you own the instance and are responsible for disposal. Owned<T> would be the same as your Lease<T>. Anything registered as "owned" must be resolved as Owned<T>. Usage as such:

public class MyThing(Owned<IFace> service) : IDisposable
{
    public void Dispose()
    {
        service.Dispose();
    }
}

API proposal would then be:

namespace Microsoft.Extensions.DependencyInjection;

public sealed class Owned<T> : IDisposable
{
    public Owned(T service);
    public T Service { get; }
    public void Dispose();
}

public static class ServiceCollectionServiceExtensions
{
    // Same exact shape as Add[Keyed]{Scoped|Singleton|Transient}, but with the service constrained to be `IDisposable`.

    public static IServiceCollection AddOwned(this IServiceCollection services, Type serviceType);
    public static IServiceCollection AddOwned(this IServiceCollection services, Type serviceType, Func<IServiceProvider, object> implementationFactory);
    public static IServiceCollection AddOwned(this IServiceCollection services, Type serviceType, Type implementationType);
    public static IServiceCollection AddKeyedOwned(this IServiceCollection services, Type serviceType, object? serviceKey);
    public static IServiceCollection AddKeyedOwned(this IServiceCollection services, Type serviceType, object? serviceKey, Func<IServiceProvider, object?, object> implementationFactory);
    public static IServiceCollection AddKeyedOwned(this IServiceCollection services, Type serviceType, object? serviceKey, Type implementationType);

    public static IServiceCollection AddOwned<TService>(this IServiceCollection services)
        where TService : class, IDisposable;
    public static IServiceCollection AddOwned<TService, TImplementation>(this IServiceCollection services)
        where TService : class
        where TImplementation : class, TService, IDisposable;
    public static IServiceCollection AddOwned<TService, TImplementation>(this IServiceCollection services, Func<IServiceProvider, TImplementation> implementationFactory)
        where TService : class
        where TImplementation : class, TService, IDisposable;
    public static IServiceCollection AddKeyedOwned<TService>(this IServiceCollection services, object? serviceKey)
        where TService : class, IDisposable;
    public static IServiceCollection AddKeyedOwned<TService, TImplementation>(this IServiceCollection services, object? serviceKey)
        where TService : class
        where TImplementation : class, TService, IDisposable;
    public static IServiceCollection AddKeyedOwned<TService, TImplementation>(this IServiceCollection services, object? serviceKey, Func<IServiceProvider, object?, TImplementation> implementationFactory)
        where TService : class
        where TImplementation : class, TService, IDisposable;
}

public class ServiceDescriptor
{
    // Again, same as [Keyed]{Scoped|Singleton|Transient}, but constrained to `IDisposable`.

    public static ServiceDescriptor Owned(Type service, Func<IServiceProvider, object> implementationFactory);
    public static ServiceDescriptor Owned(Type service, Type implementationType);
    public static ServiceDescriptor KeyedOwned(Type service, object? serviceKey, Func<IServiceProvider, object?, object> implementationFactory);
    public static ServiceDescriptor KeyedOwned(Type service, object? serviceKey, Type implementationType);

    public static ServiceDescriptor Owned<TService>(Func<IServiceProvider, TService> implementationFactory)
        where TService : class, IDisposable;
    public static ServiceDescriptor Owned<TService, TImplementation>()
        where TService : class
        where TImplemetation : class, TService, IDisposable;
    public static ServiceDescriptor Owned<TService, TImplementation>(Func<IServiceProvider, TImplementation> implementationFactory)
        where TService : class
        where TImplementation : class, TService, IDisposable;
    public static ServiceDescriptor KeyedOwned<TService>(object? serviceKey, Func<IServiceProvider, object?, TService> implementationFactory)
        where TService : class, IDisposable;
    public static ServiceDescriptor KeyedOwned<TService, TImplementation>(object? serviceKey)
        where TService : class
        where TImplemetation : class, TService, IDisposable;
    public static ServiceDescriptor KeyedOwned<TService, TImplementation>(object? serviceKey, Func<IServiceProvider, object?, TImplementation> implementationFactory)
        where TService : class
        where TImplementation : class, TService, IDisposable;
}

public enum ServiceLifetime
{
    // ...
    Owned = 3
}

Alternatively, for a slightly less "breaking change" (adding a new lifetime to the enum), the various methods above could (conceptually) wrap the implementation factory (or lack thereof through Activator.CreateInstance) into () => new Owned<TService>(factory(...)). The risk there are ripples through the ecosystem that assume TImpl : TService which would break as TImpl becomes Owned<TImpl>, and Owned<TImpl> !: TService.