Cannot access a disposed object - DI Service Provider

[roos-robert]

Hi all!

I've just started moving an application from ASP.NET Core 2.0, to Core 2.1. Everything went smooth and is working fine, except a quite important function that I had to disable for now to make the app run.

I use SignalR in this project, and have implemented a HeartBeat method, to keep the connection alive (running the app behind IIS). The solution I have implemented is following this thread on StackOverflow: https://stackoverflow.com/questions/47208844/net-core-signalr-connection-timeout-heartbeat-timer-connection-state-chan

This has been working great when running the app on .NET Core 2.0.x, but now throws the following error:

System.ObjectDisposedException
  HResult=0x80131622
  Message=Cannot access a disposed object.
  Source=Microsoft.Extensions.DependencyInjection
  StackTrace:
   at Microsoft.Extensions.DependencyInjection.ServiceLookup.ThrowHelper.ThrowObjectDisposedException()
   at Microsoft.Extensions.DependencyInjection.ServiceLookup.ServiceProviderEngineScope.GetService(Type serviceType)
   at Microsoft.Extensions.DependencyInjection.ServiceProviderServiceExtensions.GetService[T](IServiceProvider provider)
   at WebApplication.Startup.<>c__DisplayClass5_0.<<Configure>b__3>d.MoveNext() in C:\Users\MyPath\DotNetCoreTest2\Startup.cs:line 160

The part of the code throwing this error is as described above, the HeartBeat method, that looks like this

TimerCallback SignalRHeartBeat = async (x) => {   
    await serviceProvider.GetService<IHubContext<TheHubClass>>().Clients.All.InvokeAsync("Heartbeat", DateTime.Now); };
    var timer = new Timer(SignalRHeartBeat).Change(TimeSpan.FromSeconds(0), TimeSpan.FromSeconds(30));

And is placed in Startup.cs under the Configure() method, The serviceProvider is injected with DI using IServiceProvider serviceProvider like this public void Configure(IApplicationBuilder app, IHostingEnvironment env, IServiceProvider serviceProvider)

Has something changed in .NET Core 2.1 causing this?

[Corstiaan84]

Same here. @rr222cy did you get anywhere in the mean time?

[jmccannster]

Me as well. @rr222cy have you solved this?

[koskedk]

Im having a the exact same problem. Who has solved this?

[koskedk]

used StructureMap.Microsoft.DependencyInjection and now all is working...

[louislewis2]

I am having the same issue. @davidfowl Any ideas?

[davidfowl]

Yes, the service provider is disposed in Configure since it's scoped. The pattern described in that blog post isn't good. You want to use a BackgroundService to do this long running background stuff. Here's what that looks like:

The call to register the background service:

https://github.com/davidfowl/UT3/blob/fb12e182d42d2a5a902c1979ea0e91b66fe60607/UTT/Startup.cs#L46

The background service implementation:

https://github.com/davidfowl/UT3/blob/fb12e182d42d2a5a902c1979ea0e91b66fe60607/UTT/Scavenger.cs#L9

Docs here:

https://docs.microsoft.com/en-us/aspnet/core/fundamentals/host/hosted-services?view=aspnetcore-2.1

/cc @guardrex can you update the docs with the new AddHostedService method plz 😄

[louislewis2]

My problem while sharing the exact same exception, is not SignalR related.
I am using a system, that places tasks on background threads essentially, 1 of those services request an instance of IServiceProvider to be injected, the class then creates a scope and gets db contexts out etc...

This has been working for a few months already when running on 2.0, the moment after I updated to 2.1, it started failing.

Is the IServiceProvider now registered differently at all?

It would be super hard to create a repro, I am hoping that perhaps something here rings a bell, that you might be able to advise on.

@davidfowl As always thanks for the speedy response, I am certain your response helped all the SignalR guys out :)

[guardrex]

@davidfowl Got it in for the Generic Host topic ( https://github.com/aspnet/Docs/blob/master/aspnetcore/fundamentals/host/hosted-services/samples/2.x/BackgroundTasksSample-GenericHost/Program.cs#L33-L44 ) but didn't make its way over to Web Host ... until now ... dotnet/AspNetCore.Docs#6901.

[davidfowl]

This has been working for a few months already when running on 2.0, the moment after I updated to 2.1, it started failing.

https://github.com/aspnet/Hosting/issues/1446

[louislewis2]

Thanks David, greatly appreciated. 👏

[mmikirtumov]

Hi @davidfowl ,

We have a same problem. In our .net core 2.0 background service works fine. When we updated our .net core version to 2.1 system brought us the following error

Cannot access a disposed object. Object name: 'IServiceProvider'.

We have the following code _serviceProvider.CreateScope(). Could you please tell me when are you going to rollback your changes aspnet/Hosting#1106 and in wich version it will be available?

UPD: using app.ApplicationServices solved the problem, but I do not think that this is good workaround. Still waiting the undo of changes aspnet/Hosting#1106. Thanks

[davidfowl]

When the changes get rolled back you won’t be able to use them until the next version anyways unless you’re using ci builds

[mmikirtumov]

Thanks you @davidfowl ,

It would be great to understand when can we have the next patch versions of .net core 2.1?

[guardrex]

@mmikirtumov See: https://github.com/aspnet/Home#daily-builds

[davidfowl]

The next patch versions won’t have this fix. You won’t get anything related to this until at least August

[mmikirtumov]

Thank you @guardrex and @davidfowl 👍

[Eilon]

Closing this issue because the remaining work should be covered by https://github.com/aspnet/Hosting/issues/1446.

[jjxtra]

If you have a transient service constructor that takes an IServiceProvider, the service provider will be disposed. This is a bug in .NET core.

Work-around is to manage your own transient life-cycle in a pooling class.

[davidfowl]

If you have a transient service constructor that takes an IServiceProvider, the service provider will be disposed. This is a bug in .NET core.

Can you open up a new bug with your specific issue with some sample code that reproduces the problem? Closed issues are rarely looked at...