Question about Modules

[Bryan Murphy]

We've got a couple applications that have a very complex set of dependencies.  Some applications can register 50+ modules.  In other words, it's hard to boil this problem down to a small test application.

A problem we have is that on occasion, one of the modules is calling the Configure method before the Load method is called.  The configure method tries to bind up a static reference, but because Load was not called the object we need to bind to the static has not been registered with the container.

Why would Configure get called before Load?  Right now, we end up splitting the modules into two modules, and registering the module with the Load method first, and the module with the Configure method second, but this smells and doesn't help me fix the underlying problem.

Thanks,
Bryan

[Bryan Murphy]

OK, I may have finally figured this out (or it's shear dumb luck that it just happened to start working again).

Basically, when I overrode Load() and Configure(), there were a few places where I missed calling base.Load() and base.Configure().  Putting those in place seems to have fixed my problem.

Bryan

[Carl Hörberg]

why is the documentations recommendation to inherit from Module instead of simply implement the IModule interface? i use it all the time, works flawlessly for me?

--

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.

[Nicholas Blumhardt]

Load provides a ContainerBuilder, which is easier/more obvious to configure than IContainer. Plus there's AttachToCompinentRegistration() goodness.

If you're happy implementing IModule that's perfectly valid.

[Steven Burman]

Sorry to hijack this thread but I am not sure that my observation
deserves its own. I found an intersting quirk in using modules that is
not obvious (at least not to me). I am not sure how modules are
implemented in v2 but it may be worth considering the default scope
handling.

For example, we wanted all of our registrations to be container scoped
by default, so we set this option as soon as we create the
ContainerBuilder instance. When we then proceed to load modules the
default for each module reverts to the system default (which is
singleton in the version we are running). This seemed to be against my
intuition but may make sense?

I expected the test below to pass... but it fails. Any thoughts on how
this should be handled?

[Test]
public void ContainerBuilderDefaultAppliesToLoadedModules()
{
var cb = new ContainerBuilder();
cb.SetDefaultScope(InstanceScope.Container);
cb.RegisterModule(new DummyModule());

var container = cb.Build();
var outerDummy = container.Resolve<IDummy>();

IDummy innerDummy;
using (var inner = container.CreateInnerContainer())
{
innerDummy = inner.Resolve<IDummy>();
}

//should not be the same because I expected the default
scope to be applied to the module
Assert.AreNotSame(outerDummy, innerDummy);
}

internal class DummyModule : Module
{
protected override void Load(ContainerBuilder builder)
{
builder.Register<Dummy>().As<IDummy>();
}
}

[Nicholas Blumhardt]

Hiya Steven,

There was another thread on a similar topic you might get some info from - http://groups.google.com/group/autofac/browse_thread/thread/224d1339fe8ed00a

You shouldn't have too much trouble doing this in your own custom base Module class, either deriving from Module or implementing IModule directly.

Regarding v2, I'm not sure the ability to change the default scope is going to carry over - thoughts on this welcome.

HTH

Nick

2009/12/22 Steven Burman <steven...@gmail.com>

           }
       }