Solution for accumulation of Disposable transient services

Given a service:

public class Repository : IRepository, IDisposable { ... }

It is injected as a transient:

static void Main(string[] args)
{
    var serviceProvider = new BrowserServiceProvider(configure =>
    {
        configure.Add(ServiceDescriptor.Transient<IRepository, Repository>());
    });

    new BrowserRenderer(serviceProvider).AddComponent<App>("app");
}

If this service is injected into a component, it is never disposed even when navigating away from the component:

@page "/"
@inject IRepository Repository
...

Is this a bug or is there a functionality available to dispose injected services implementing IDisposable?

[dazinator]

Is there any reason why Blazor couldn’t use an IServiceScope for page / component activation (as also mentioned by @rstropek ) - Dispose of that scope when the page / component is disposed.

This means that anything you resolve as a transient is kept in memory until the DI scope is disposed.

So if blazor used a scope and disposed of it appropriately then problem solved?

P.s a similar pattern can be used successfully in other UI stacks where dependencies are injected. For example in windows forms or wpf, or Xamarin forms apps, when navigating to a new UI you might have something conceptually like this:

E.g:

Public void NavigateTo<T>()
{
    using (var scope = sp.CreateScope())
    {
        var nextUi = scope.GetRequiredService<T>();
        nextUi.ShowDialog(); // I.e in windows forms this would block and control return once form was closed.
    // if not using a show method that blocks you'd adjust this so that the scope was kept around and only disposed once form was closed.
    }
}

[SteveSandersonMS]

scoped is currently not used, is it?

Correct

One design problem with the current behavior is that the component receiving the service does not know whether it is transient or singleton

Isn’t that the same for, say ASP.NET MVC controllers receiving services as constructor args?

The ASP.NET Core docs says: The container will call Dispose for IDisposable types it creates. As far as I know transient instances will be disposed at the end of the request in ASP.NET Core. So Blazor’s behavior would be different.

For singletons, it doesn’t make sense ever to dispose the instance (except if the IServiceContainer itself was disposed). For transients, I agree it would make sense to dispose them when the component itself is disposed.

What I’m not currently sure about (because I haven’t yet investigated) is how that’s even possible under the IServiceProvider contract. That interface only exposes object GetService(Type serviceType), which doesn’t provide any mechanism to indicate that we want a service within a certain scope, or to be told whether the supplied service instance should later be disposed or not.

Clearly this requires a bit more research so I’ll leave this issue open with a modified title.