As a brief follow up to my  last post here I thought I'd quickly post about something I've
been doing lately with my own  windsor configurations, which is pretty minor - but saves me a little grief when it comes to refactoring etc.

Basically I have this extension method:

public static ComponentRegistration<> RegisterTransient(this IWindsorContainer container, ComponentRegistration registration)

{

 container.Register(registration.LifeStyle.Transient);

 return registration;

} 

Which then lets me do this:

var serviceA = container.RegisterTransient(Component.For() .ImplementedBy());var serviceB = container.RegisterTransient(Component.For() .ImplementedBy());
container.Register(Component.For().Named("service.staff")

 .ImplementedBy().ServiceOverrides(ServiceOverride

 .ForKey("Repositories").Eq(serviceB.Name, serviceA.Name))); 
var staffService = (StaffService)container.Resolve(); 
Assert.IsType(staffService.Repositories[0]);

Assert.IsType(staffService.Repositories[1]); 

notice the lack of strings when registering service overrides... it's a minor thing, but I find it quite handy... plus it generally makes it easier to identify the lifestyle of the components being registered because it's a little more in your face, i.e. your making an explicit decision... though anywhere that lifestyle poses a risk you should obviously be writing some unit tests to verify your getting the expected behavior when resolving that service
anyway.

Also, while looking at ComponentRegistration -the other nice thing about the fluent component registration is it works quite well for add-ons that introduce their own services which aren't loaded into a seperate app domain or child kernel ...

Just give the add-in an installation "helper" which only exposes a method taking a ComponentRegistration for registering the component... you can then defer when those services are actually registered in the kernel, and can use the names of the components or other info to unregister them if the add-in is turned off (obviously this is a rainy day scenario and there are problems with this approach, but so far I've found it to work quite well).