DependencyResolver.Current.GetService versus IComponentContext

[birchoff]

I am currently getting intermittent LifetimeScope disposed errors in
my ASP.NET MVC 3 application, which is using autofac 2.4.5.724
(according to the details of the autofac.dll in windows). I have read
the following wiki article on the autofac site

http://code.google.com/p/autofac/wiki/Concurrency

and would like to know if there is any difference in using the ASP.NET
MVC 3 autofac intgration point, DependencyResolver.Current versus a
reference to IComponentContext which is injected into the consumer as
outlined in the article at the previous link. If there is a difference
between the two can you explain what that difference is and in what
context either should be limited to.

[Nicholas Blumhardt]

Hi - there's no difference I'm aware of between the two methods of accessing the container. One essentially calls the other.

Can you please post more detail of the error you are seeing - ideally the exception message plus a full stack trace?

Also, how are you registering the component that has IComponentContext injected? Register(c => x) or RegisterType()? If using the delegate-based version, you can't store the c parameter and instead must resolve IComponentContext from it.

Cheers,

Nick

--
You received this message because you are subscribed to the Google Groups "Autofac" group.
To post to this group, send email to aut...@googlegroups.com.
To unsubscribe from this group, send email to autofac+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/autofac?hl=en.

[birchoff]

Thanks for that clarification. I do have another related question.
When a class has been registered as per request and single instance
when I do the following

DependencyResolver.Current.GetService<Class>()

inside a method that is executed by a BeginRequest event handler
defined in Global.asax.

what instance of class is being returned? is it the per request
instance or the singleton instance?

On Sep 8, 12:17 am, Nicholas Blumhardt <nicholas.blumha...@gmail.com>
wrote:

> Hi - there's no difference I'm aware of between the two methods of accessing
> the container. One essentially calls the other.
>
> Can you please post more detail of the error you are seeing - ideally the
> exception message plus a full stack trace?
>
> Also, how are you registering the component that has IComponentContext
> injected? Register(c => x) or RegisterType()? If using the delegate-based
> version, you can't store the c parameter and instead must resolve
> IComponentContext from it.
>
> Cheers,
>
> Nick
>

[Nicholas Blumhardt]

It would be whichever was registered last- Autofac treats the two registrations as two providers of the same service, irrespective of lifetime settings. In such cases last-in always wins.

Cheers
Nick

[birchoff]

Is that true if the one of the instances are registered as a named
service?

On Sep 17, 12:22 am, Nicholas Blumhardt <nicholas.blumha...@gmail.com>
wrote:

> It would be whichever was registered last- Autofac treats the two registrations as two providers of the same service, irrespective of lifetime settings. In such cases last-in always wins.
>
> Cheers
> Nick
>

[Nicholas Blumhardt]

No- named and unnamed services are treated as unrelated

[birchoff]

In that case I am pretty much stumped as to what my problem is. I have
a class that takes the IComponentContext as a constructor
parameter(Yes I know it is not good to do this, and if there is a
better way I would love to move to it). This class is registered as
per http request as follows

this.RegisterType<Class>().InstancePerHttpRequest();

It is also registered as a named single instance.

var Application = "Application";
this.RegisterType<Class>().Named<Class>(Application).SingleInstance();

Unfortunately for me my app has a hisenbug where every so often the
request that is processing will end up referencing a disposed
IComponentContext and get the following error

Cannot access a disposed object.
Object name: 'Instances cannot be resolved and nested lifetimes cannot
be created from this LifetimeScope as it has already been disposed.'.

I was able to get the problem to disappear again by having Class take
a IComponentContext factory:

public Class(func<IComponentContext> componentContextFactory)

but I feel like this may just be hiding the problem instead of fixing
it.

On Sep 18, 1:00 pm, Nicholas Blumhardt <nicholas.blumha...@gmail.com>
wrote:

> No- named and unnamed services are treated as unrelated
>

[Nicholas Blumhardt]

Sounds like a painful situation! The disposed context must be a per-request one. What is the app doing when the exception is thrown? If you can capture a stack trace it might contain some clues.

Cheers,
Nick

[birchoff]

According to the source code of autofac. it looks like the module that
disposes of the requestlifetimescope runs on EndRequest. My IIS event
order is a bit rusty but is it possible for that event to fire before
the view has been sent to the browser. In particular I am wondering if
EndRequest gets called before a RenderAction completes? So I guess my
questions effectively boil down to:

Do Child Actions, invoked via RenderAction share the same
RequestLifetimeScope as their Parent Action?

on a separate but related note? does anyone know if it is at all
possible for RenderAction call to end up on a different thread?

On Sep 23, 6:40 am, Nicholas Blumhardt <nicholas.blumha...@gmail.com>
wrote:

> Sounds like a painful situation! The disposed context must be a per-request one. What is the app doing when the exception is thrown? If you can capture a stack trace it might contain some clues.
>
> Cheers,
> Nick
>

[Nicholas Blumhardt]

I'm not aware of any implicit multithreading in RenderAction(), and I'm reasonably sure that rendering occurs before EndRequest. Not 100% sure that there aren't special cases though :)

A stack trace from the exception may switch some lightbulbs on. Also, a description of your setup including the problematic components would help a lot.

Cheers,

Nick