I'm am trying to branch a number of child containers from a basic set of registrations in order to facilitate different configuration settings.
I thought based on Mark Seemanns reply on how child containers work that I could use child containers to override specific components in a base registration. However I does not seem to work as Seemann claims.
According to Mark this should work:
[TestMethod]
public void OverrideRegistrationInParentContainer()
{
//IBusinessComponent depends on IBasicComponent
var parentContainer = new WindsorContainer();
parentContainer.Register(Component.For<IBasicComponent>().ImplementedBy<BasicComponent>()); //Returns 42
parentContainer.Register(Component.For<IBusinessComponent>().ImplementedBy<RealBusinessComponent>()); //Returns the result of IBasicComponent
var childContainer = new WindsorContainer();
childContainer.Register(Component.For<IBasicComponent>().ImplementedBy<BasicComponent2>()); //Returns 40
parentContainer.AddChildContainer(childContainer);
var service = childContainer.Resolve<IBusinessComponent>();
Assert.AreEqual(40, service.GetBusinessValue()); //This fails with the actual value being 42
}
However all dependencies are apparently resolved from the parent.
If i remove the IBasicComponent registration from the parentContainer, I am not even able to resolve the dependency due to missing registrations.
Can anyone explain how you get the container to behave as Seemann claims, or is the WindsorContainer really unable to handle this type of configuration in a graceful manner?
The behavior you're referring to used to work in old Windsor versions but was altered in more recent versions.
Basically this is a bug, and it would allow components from child container to be visible outside its scope (when a component form parent takes a dependency on a component from child)
So the dependencies are allowed to go from child --> parent but not the other way around.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With