I think there's 3 levels of skill involved with the Castle IoC implementation... first off you get a handle of the XML configuration, registering components, using existing facilities... pretty much getting away largely with cut 'n paste coding.

Then you get to the intermediate level.. writing basic facilities, tweaks to the component model, writing your own sub dependency resolvers or component activator, having a go with binsor configuration.

I think the third level is reserved for the Castle team alone... ;o)

This post is going to be straddling the beginner to intermediate kinda level... which is generally all I ever reach with Castle's IoC... it's not often you have to dig deeper day-to-day... though it's always good to know there is a lot of untapped potential there.

So.. for today, say you have a component, like the Base4Host, which has some explicit constructors:


You can register it the container easy enough, and provide values for them in XML configuration, but what if you want to do the same programatically... generally your first stop would be to examine the IWindsorContainer for a suitable overload... alas it doesn't get us far, so we dig in to the underlying IKernel itself... the kernel exposes some possible candidates:


So you experiment with them, but supplying the dictionary of extended properties does nothing... hmm... time to file a bug report? well no... extended properties having nothing to do with satisfying parameter or property dependencies on your component - not directly at least.

So why don't we just create the component ourselves.. and then add it to the container?

Well you can, via the Kernel.AddComponentInstance method but you're going to miss out on some things... for instance the startable facility won't be "concerned" with your component, and as such if it implements IStartable it won't get started and stopped... Though I haven't confirmed this, I dont think the container will bother to dispose of any IDisposable components registered in this fashion either... the container doesn't consider itself the owner of the component (and generally this is what we want).

So we're going to have to get a little more intimate with the container implementation ... so every time a component is registered in the container a corresponding ComponentModel is generated for the component, this basically keeps track of the:

• Components dependencies
• Constructor candidates
  
• Parameters (sounds like us...)
• Name, implementation type and service type.
• Lifecycle, Lifestyle...
• And some other stuff you can discover for yourself.

Now we could get heavy handed and jump into contributing to the construction of the component model itself... but it's pretty uncessary, we just want to tweak the end result... so we can use an event handler on the Kernel - ComponentModelCreated.

So here we have an implementation that solves our problems... This is being implemented inside a facility, but you could do this anywhere... wire it up in your custom container that's derived from WindsorContainer maybe, obviously you want to remove the if statement for checking the Implemenation type is Base4Host though. :)


Now I can register my component by doing something like this:


Here we're passing all our additional parameters as a Dictionary<string, object> inside our IDictionary of additional properties....  this isn't the most elegant implementation, but this is all code internal to a single facility so it's not really important to me... and it gets the job done just fine.