Lee Henson has implemented a Castle Windsor facility for re-motion’s ObjectFactory class. With it, it is possible to have the container resolve components that are mixed by re-motion. Lee’s original intention was to have a mixed MonoRail controller, which should now be perfectly possible.
Quoting from Lee’s announcement on the Castle developers list:
Sample usage is the specs in the project, but sample (notepad) code
<wherever you are creating your container>
var remotionFacility = new RemotionFacility
var component = container.Resolve<ComponentWithAvailableMixins>();
UPDATE: We now have a Remotion-Contrib repository, find the facility here: https://svn.re-motion.org/svn/Remotion-Contrib/WindsorFacility/trunk/.
Thanks a lot for making this work, man!
How it works
Lee and I mailed around a little to see how to do this, and while Lee did all the implementation work, it’s quite easy to explain what it does. The RemotionFacility is a simple Windsor facility that hooks up a special RemotionActivator class for components that have mixins configured. That activator uses re-motion’s ObjectFactory to instantiate the component (after all of its constructor dependencies have been resolved) – and voilà, there is your mixed component.
What can go wrong
The RemotionFacility has constructors allowing you to use an auto-generated configuration, specify the assemblies to scan, or specify a dedicated MixinConfiguration instance. However, even when you specify the configuration by hand, re-motion will still want to do an assembly scan of those assemblies in your bin folder at runtime. This is the default policy and cannot be easily disabled in the current re-motion trunk revisions, so you might get exceptions when you have assemblies with dangling references in your project’s bin folder. Such an exception is nearly always a deployment bug, so you should really clean up your folder, but if you can’t (or don’t want to), the only way around it currently is to set a custom ITypeDiscoveryService via ContextAwareTypeDiscoveryUtility.SetDefaultInstance(…) before doing anything mixin-related. (Or, better, before doing anything re-motion-related, since a lot in re-motion is mixin-related.)
(This will be fixed to make it easier in the future.)
EDIT (2009-02-10): Updated link to facility.
EDIT (2009-03-23, 2011-04-22): Updated link to facility. Again.