MVC integration question

[gkdm]

Hi, two questions:
1. When i register my dependencies (as in the following code) I get
all of them registered in the application
container not in the Request container of the ContainerProvider
despite i used HttpRequestScoped() on registration. What am i no
understanding?

2. I downloaded the Autofac code and noticed two things, one- it's
very well written, Shafo! two- the sample web application uses many
different constructs not present in the current release
(ShareInstanceIn, WebLifeTime, SingleSharedInstance) what are does
changes?

[Nicholas Blumhardt]

Hi!

1. Although they're registered in the app container can you still
resolve instances from the request container? This should be fine.

2. The code corresponding to the current (1.4) release is in /branches/
1.4 while the trunk is the next version not yet complete or compatible
with 1.x

Hope this helps

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
> .
>
>

[gkdm]

How to register them in the request container so that they would be
disposed correctly?

On Nov 10, 6:29 am, Nicholas Blumhardt <nicholas.blumha...@gmail.com>
wrote:

[Nicholas Blumhardt]

Have you checked to see that they're not being disposed correctly?

> .
>
>

[Dario Solera]

I am in the same situation (ASP.NET MVC): RequestContainer works fine
the first time (the first request upon app startup), then the
component I registered (a NH ISession) is no longer instantiated (I
hooked on OnActivated to verify that) and it basically works as a
singleton, although Dispose is called on the component (thus causing
trouble during the subsequent request). I tried with
both .ContainerScoped() and .HttpRequestScoped() with no luck. If I
remove the DisposeRequestContainer call in Application_EndRequest,
everything works fine, but at this point the component is never
disposed (and never re-activated).

In short: calling DisposeRequestContainer the component is disposed
but never re-activated; not calling DisposeRequestContainer the
component is not disposed and never re-activated.

Could it be that ISession depends on ISessionFactory, that is
registered as singleton? On a broader perspective, does
CreateInnerContainer have any effect on the parent container?

I am using the latest 1.4 revision (checked out a few hours ago).

Thanks.

On Nov 11, 1:08 am, Nicholas Blumhardt <nicholas.blumha...@gmail.com>

[Nicholas Blumhardt]

Hi Dario,

It is more likely that something that depends on ISession is a
singleton, e.g. A repository - but that still sounds inconsistent with
the disposal behaviour you noted..

Are you registering services in RequestContainer? That would explain
it (all services should be registered in the app container.)

If that isn't it, can you post details of the web server you're using,
and if possible a sample of your container configuration?

Thanks,

Nick

> For more options, visit this group at http://groups.google.com/group/autofac?hl=en
> .
>
>

[Dario Solera]

He he, my bad. ISession and ISessionFactory were registered correctly.
The problem was that all other components, depending on ISession, were
registered as singleton (I forgot to add .FactoryScoped()), thus the
application behaved unexpectedly.

Everything is fine now.

On Dec 23, 10:07 pm, Nicholas Blumhardt <nicholas.blumha...@gmail.com>
wrote:

> Hi Dario,
>
> It is more likely that something that depends on ISession is a  
> singleton, e.g. A repository - but that still sounds inconsistent with  
> the disposal behaviour you noted..
>
> Are you registering services in RequestContainer? That would explain  
> it (all services should be registered in the app container.)
>
> If that isn't it, can you post details of the web server you're using,  
> and if possible a sample of your container configuration?
>
> Thanks,
>
> Nick
>

[Nicholas Blumhardt]

Good to hear :)

In v2 we're switching to factory-by-default to prevent this common source of bugs.

Nick.

2009/12/24 Dario Solera <dari...@gmail.com>

[Bryan Murphy]

Would it be useful to have some sort of container scoped only method of registration?  That way you can never resolve it a reference the top level container (it would throw an error), instead you could only resolve it from an inner container?  I've gotten bitten by this on a number of occasions and it can be tricky tracking down which component is registered with the wrong scope. 

Factory by default helps, but doesn't solve the problem entirely.

Bryan

[Nicholas Blumhardt]

If you use .HttpRequestScoped() in Autofac 2, you'll get an exception if you try to resolve the component from the app-level container.

This sets the component to use InstanceSharing.Shared and a Lifetime of MatchingScopeLifetime.

There isn't a convenient way to set it, but the combination of InstanceSharing.None and MatchingScopeLifetime would have the effect you're looking for.

public static class BryanExtensions // :P

{

        public static RegistrationBuilder<TLimit, TActivatorData, TStyle>

            ManyInstancesPerHttpRequest<TLimit, TActivatorData, TStyle>(

                this RegistrationBuilder<TLimit, ActivatorData, TStyle> registration)

        {

            registration.RegistrationData.Sharing = InstanceSharing.None;

            registration.RegistrationData.Lifetime = new MatchingScopeLifetime(scope => WebLifetime.Request.Equals(scope.Tag));

            return registration;

        }

}

I.e. you can then use builder.Register(...).ManyInstancesPerHttpRequest() instead of the default InstancePerDependency(), and .HttpRequestScoped() where you want sharing within a request.

The error message might not be as descriptive as you'd like though...

Give it a whirl, I'd be interested to know if it helps!

Cheers,

Nick

2009/12/28 Bryan Murphy <bmurp...@gmail.com>