Is there a way to check if the Scope was disposed? about simpleinjector HOT 5 CLOSED

Can you supply me with a full stack trace of the exception?

from simpleinjector.

Unhandled exception during request [500]   [ActivationException] : 
Cannot access a disposed object.  Object name: 'SimpleInjector.Scope'.     at
 SimpleInjector.InstanceProducer.GetInstance()     at
 SimpleInjector.Container.GetInstance[TService]()     at
 MyProject.ServiceConfig.<>c__DisplayClass11_0.<Config>g__Create|1()     at
 lambda_method(Closure )     at
 SimpleInjector.InstanceProducer.GetInstance()     at
 SimpleInjector.Container.GetInstance[TService]()     at
 MyProject.Services.Account.CustomRoleProvider.GetRolesForUser(String username)
 MyProject.MiniProfilerModule.onEndRequest(Object sender, EventArgs e)     at
 System.Web.HttpApplication.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()     at
 System.Web.HttpApplication.ExecuteStepImpl(IExecutionStep step)     at
 System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)
[ObjectDisposedException] : `Cannot access a disposed object.  Object name: 'SimpleInjector.Scope'.`     at
 SimpleInjector.Scope.ThrowObjectDisposedException()     at
 SimpleInjector.Scope.GetInstanceInternal(ScopedRegistration registration)     at
 SimpleInjector.Scope.GetInstance[TImplementation](ScopedRegistration registration, Scope scope)     at
 SimpleInjector.Advanced.Internal.LazyScopedRegistration`1.GetInstance(Scope scope)     at
 lambda_method(Closure )     at
 SimpleInjector.InstanceProducer.GetInstance()  

Registration is done like this:

        c.Register<Tracker>(Lifestyle.Scoped);
        c.Register<IUnitOfWork>(Create);

Create is a method from my previous message

from simpleinjector.

What you're dealing with is a a combination of corner cases:

• The (old) ASP.NET Web frameworks end the request (in my opinion) too early in the request's lifecycle, which can cause object disposed exceptions when you run code on the end of the request. Years back, I've spent countless hours researching this and trying to work around these issues when I was building Simple Injector integration packages for these frameworks, but unfortunately, without success.
• Simple Injector still references that scope and returns it when asked, even though it was disposed. While it should -and normally will- return null.

Having Simple Injector correctly return null from its GetCurrentScope, however, will unlikely fix your issue, because you want to resolve an instance from a scope. It being null will still not allow you to resolve scoped instances.

Unfortunately, there's little I can do here, because:

1. This is the way those web frameworks are designed.
2. I'm not actively developing those integration libraries any longer. I only release new versions with new versions of the Simple Injector core library to keep them compatible, but that's about it.

I would, therefore, suggest a different solution. Here are some suggestions:

• Try to run this profiling code a bit earlier in the request lifecycle to ensure that the Scope isn't yet disposed.
• Load the required dependencies earlier, for instance at the beginning of the request, store them, and use them at the end of the request. One way to store them is putting them in Request.Items; that dictionary will still be available at the end of the request, if I'm not mistaken.

I hope this helps

from simpleinjector.

thanks a lot for your explanation - I'll try to think on alternative ways.

return null from its GetCurrentScope, however, will unlikely fix your issue, because you want to resolve an instance from a scope. It being null will still not allow you to resolve scoped instances

Actually it would help as only Tracker is registered as Scoped and can't be resolved but I'm fine not to track at that moment during this edge case. I.e. UnitOfWork that is required during the work of the profiler is resolved fine since it's registered as Transient.

from simpleinjector.

I struggled with the weird request lifestyle model of those web frameworks years ago, which is one of the many reasons I moved to design that I found easier to reason about, which is the use of an ICommandHandler<T> abstraction, which I described here. This allows me to apply cross-cutting concerns like your tracker logic on the boundaries of executed commands.

Changing your application to a design as described in that article might be quite an undertaking, and might not be feasible for you at the moment, but it might give you some inspiration on ways of looking at this from a different angle.

from simpleinjector.