Different Implementations of IMappingExecutor?

Mar 5, 2012 at 5:48 PM

I'm looking to extend TFS Deployer to support other types of workloads (beyond deployment) by having a different implementation of IMappingExecutor, but not being really familiar with AutoFac, the specific implementation details are eluding me.

I believe what I need to do is update DeployerContainerBuilder register multiple implementations (using different service names?!?) and select the correct one using a parameterized delegate around here:

                c => new TransparentOwnedMappingExecutor(c.ResolveNamed<Owned<IMappingExecutor>>("implementor")))

Problem is, it is either the type registration itself (RegisterType<>) which needs to be selected by parameter (which I don't see a way to do with AutoFac), or there needs to be a selection occurring in the .Register(...) call which I've not been able to work out the correct syntax for (as yet). I'm assuming the parameter would simply be added to the executor call within ProcessMappings(), causing the selection delegate to resolve which implementation to use, but this is only in my head as yet.

Can anyone point me in the right direction here? If I'm not able to extend this in this way it means basically just thow out TFSDeployer or move to an older codebase where dependencies are declared rather than inferred at runtime, where I can simply use a factory to make the implementation decision....

One minor comment: on the plus side, the use of AutoFac helps to make the system flexible, but it also seems to make it MUCH more painful to work with and understand by someone not already fluent in this entire codebase; since all the dependencies are injected and resolved at runtime, it seems damn near impossible to really see what the behavior will actually be without knowing every line of TFSDeployer AND AutoFac's behavior ahead of time, Just my 2/100 of a buck, if a goal here is to allow easy extension by others; if this isn't a goal then the codebase can be as cryptic and obtuse as you want :-)



Mar 7, 2012 at 11:55 AM


The Autofac registration of that particular component is more complicated than most because it also uses the Owned feature of Autofac to control lifetime scope but does so in a way that the consuming code doesn't need to care. I definitely intend to refactor DeployerContainerBuilder into Modules for easier deciphering and maintenance.

Additionally, the majority of interfaces in the Deployer code base exist to enable an interception point for testing, not for alternate production implementations. The focus of TFS Deployer is very narrowly scoped at deployment (it's in the name) so while you're welcome to customize it yourself and publish those changes, I probably won't merge any contributions that deviate from this goal.

To make the change, replace the "MappingExecutor" reference in the snippet you quoted above with your own implementation and make the decision inside your code to proxy calls back to the original MappingExecutor or run your own logic based on whatever conditions you desire.