We Keep Coding

Structuremap 3 multiple decoration

I am trying to create a dependency graph in StructureMap 3 with a chain of decorators:
Each instance has a constructor with multiple arugments, but exactly one argument of an inner IGeocoder, e.g.
public SomeCachingGeocoder(IGeoCoder inner, IFoo somethingElse)
I am hooking them up like this:
For<OviGeoCoder>().Use<OviGeoCoder>();
For<SqlCachingGeocoder>().Use<SqlCachingGeocoder>().Ctor<IGeoCoder>().Is<OviGeoCoder>();
For<RedisCachingGeocoder>().Use<RedisCachingGeocoder>().Ctor<IGeoCoder>().Is<SqlCachingGeocoder>();
For<IGeoCoder>().Use<RedisCachingGeocoder>();
But I get
Bi-directional dependency relationship detected! Check the StructureMap stacktrace below:
1.) Instance of SOAM.Services.IGeoCoder (SOAM.Services.Geocoding.RedisCachingGeocoder)
2.) new RedisCachingGeocoder(Default of IDatabase, Default of IGeoCoder)
3.) SOAM.Services.Geocoding.RedisCachingGeocoder
4.) Instance of SOAM.Services.IGeoCoder (SOAM.Services.Geocoding.RedisCachingGeocoder)
5.) new HomeController(Default of IGeoCoder, Default of IAlertService)
6.) SOAM.Web.Controllers.HomeController
7.) Instance of SOAM.Web.Controllers.HomeController
8.) Container.GetInstance(SOAM.Web.Controllers.HomeController)
Any ideas how to solve this?

DecorateAllWith allows auto-wiring by default and allows stacking decorators in a quite easy way:
For<IGeoCoder>().Use<OviGeoCoder>();
For(typeof(IGeoCoder)).DecorateAllWith(typeof(SqlCachingGeocoder));
For(typeof(IGeoCoder)).DecorateAllWith(typeof(RedisCachingGeocoder));

If for some reason you cannot use DecorateAllWith() then this should work:
var container = new Container(
c =>
{
c.For<IFoo>().Use<Foo>();
c.For<IGeoCoder>().Add<OviGeoCoder>().Named("default");
c.For<IGeoCoder>()
.Add<SqlCachingGeocoder>()
.Ctor<IGeoCoder>()
.Is(ctx => ctx.GetInstance<IGeoCoder>("default"))
.Named("SqlCaching");
c.For<IGeoCoder>()
.Use<RedisCachingGeocoder>()
.Ctor<IGeoCoder>()
.Is(ctx => ctx.GetInstance<IGeoCoder>("SqlCaching"));
});
Wanna find what's the difference when using Use vs Add? Take a look here

Registering instances of same type with Simple Injector

I have just picked up Simple Injector and all I currently want to do is this:
Container.Register<IMessageHandler>(() => new MessageHandlerOne());
Container.Register<IMessageHandler>(() => new MessageHandlerTwo());
I'm just trying to register two message handlers, so I can later iterate through them.
To get back these registered instances, this method sounds like it would do the trick.
var instances = Container.GetAllInstances<IMessageHandler>();
//why doesn't instances contain both MessageHandlerOne, and MessageHandlerTwo ?
Instead this returns back an empty IEnumerable.
What am I doing wrong? For something named Simple Injector you would think this would work? Am I thinking about this the wrong way?

What you are trying to do should fail with an exception on the second call to Container.Register<IMessageHandler> since the Simple Injector API clearly differentiates the registration of collections.
In other words, if you want to resolve a collection, you should register a collection:
Container.Collection.Register<IMessageHandler>(
typeof(MessageHandlerOne),
typeof(MessageHandlerTwo));

Having Automapper use services constructed by a Autofac with WebApi

I'm using WebAPI + Autofac + Automapper, with a repository for data access. I need to map a model to my domain entities, specifically, I need to convert an identity value to the actual entity. No big deal, right? I've done this in MVC with no problem. I will simplify what I am doing to expose the essentials.
public class EntityConverter<T> : ITypeConverter<int, T>
where T : Entity
{
public EntityConverter(IRepository<T> repository)
{
_repository = repository;
}
private readonly IRepository<T> _repository;
public T Convert(ResolutionContext context)
{
_repository.Get((int) context.SourceValue);
}
}
Repositories are registered with Autofac, and are managed as InstancePerApiRequest because of session/transaction management. So, I need to register my converter in that same scope:
builder.RegisterGeneric(typeof(EntityConverter<>))
.AsSelf()
.InstancePerApiRequest();
The Automapper config looks something like:
var container = builder.Build(); // build the Autofac container and do what you will
Mapper.Initialize(cfg => {
cfg.ConstructServicesUsing(container.Resolve); // nope nope nope
// configure mappings
cfg.CreateMap<int, TestEntity>().ConvertUsing<EntityConverter<TestEntity>>()
});
Mapper.AssertConfigurationIsValid();
So here's the part that sucks. I am to understand Automapper requires the ConstructServicesUsing guy to be set before you build your config. If you set it later, it won't be used. The example above won't work because container is the root scope. If I try and resolve EntityConverter<TestEntity>, Autofac will complain that the requested type is registered for a different scope, and the one you're in ain't it. Makes sense, I want the scope created by WebApi.
Let me pause a sec and cover one fact about WebApi dependency injection (I don't really think this is Autofac-specific). WebApi creates an IDependencyScope for the request, and stashes it in the HttpRequestMessage.Properties. I can't get it back again unless I have access to that same HttpRequestMessage instance. My AsInstancePerApiRequest scoping on IRepository and my converter thus rely on that IDependencyScope.
So, that's really the meat and potatoes of the problem, and I really frustrated with this difference from MVC. You can't do
cfg.ConstructServicesUsing(GlobalConfiguration.Configuration.DependencyResolver.GetService);
That's equivalent to using container.Resolve. I can't use
GlobalConfiguration.Configuration.DependencyResolver.BeginScope().GetService
because A) that creates a new scope next to the one I actually want B) doesn't really let me clean up the new scope I created. Using Service Locator is a new way to have the same problem; I can't get to the scope WebApi is using. If my converter and its dependencies were single instance or instance per dependency, it wouldn't be a problem, but they aren't, so it is, and changing that would create lots more problems for me.
Now, I can create AutoMapper config with Autofac and register it as a single instance. I can even create per-request IMappingEngine instances. But that doesn't do me any good if the service constructor always uses that single delegate you register at the beginning, which has no access to the current scope. If I could change that delegate per each mapping engine instance, I might be in business. But I can't.
So what can I do?

Another option, this time it's built-in, is to use the per-map options:
Mapper.Map<Source, Destination>(dest, opt => opt.ConstructServicesUsing(type => Request.GetDependencyScope().GetService(typeof(YourServiceTypeToConstruct))));
Don't bother with setting up the global IoC config in your mapping configuration.
Another option is to use your IoC tool to configure how to instantiate the MappingEngine:
public MappingEngine(
IConfigurationProvider configurationProvider,
IDictionary<TypePair, IObjectMapper> objectMapperCache,
Func<Type, object> serviceCtor)
The first one is just Mapper.Configuration, the second should probably be a singleton, and the third you can fill in with the current nested container's resolution. This would simplify from having to call the Map overload every time.

Update: Automapper was updated to support that feature. See #Jimmy Bogard 's answer
This solution could be not very nice, but it works. The solution relates to WebAPI 2, I'm not sure about previous versions.
In WebAPI 2 you can get current IDependencyScope from current HttpRequestMessage via GetDependencyScope() extension method. Current HttpRequestMessage is stored in the Items property of the current HttpContext. Knowing that your factory could look like:
Mapper.Initialize(cfg =>
{
cfg.ConstructServicesUsing(serviceTypeToConstruct =>
{
var httpRequestMessage = HttpContext.Current.Items["MS_HttpRequestMessage"] as HttpRequestMessage;
var currentDependencyScope = httpRequestMessage.GetDependencyScope();
return currentDependencyScope.GetService(serviceTypeToConstruct);
});
// configure mappings
// ...
});

This may or may not be suitable for you.. but here goes:
We recently did this.. for model binders in MVC. Our model binders (on GET requests) now use Ninject-managed Services to build models.
Basically, we inject a factory (using Ninject's Factories extension.. perhaps there is a similar one for Autofac) into an "AutomapperBootstrapper" class, which in turn creates Automapper mapping Profile's and adds them to Automapper. Somewhat like this:
Mapper.Initialize(cfg =>
{
cfg.AddProfile(_factory.CreateServiceViewModelMappingProfile());
// etc..
});
The mappings Profile's themselves use MapFrom(), which is evaluated each time a mapping occurs. Something like this:
Mapper.CreateMap<Service, ServiceViewModel>()
.ForMember(x => x.Regions,
opt =>
opt.MapFrom(x => getRegions()))
private IEnumerable<Region> getRegions() {
return _factory.CreateTheService().GetRegions();
}
Each time the model binder is fired up, Ninject still wires up all dependencies for the request and it all filters down.
(For those interested, this setup basically lets us do this: /Area/Controller/Action/12, and our controller action method is this:
[HttpGet]
public ActionResult Action(ServiceViewModel model) {
// ...
}
).

NInject ConstructorArgument with lambda expression

Is there any way to create an instance of ConstructorArgument using lambda expression instead of hardcoded string to define the name of the property?
Something like this:
var validator = Ioc.Kernel.Get<Validators.Security.UserGroupValidator>(new ConstructorArgument( x => x.ValidationDictionary, new ValidationDictionary())
In my case, the ValidationDictionary is not the same in many places and for this reason, I can't use a Provider.

You can use the ToConstructor binding like
http://www.planetgeek.ch/2011/05/28/ninject-constructor-selection-preview/
Bind<UsergroupValidator>().ToConstructor(_ => new Usergroupvalidator(new ValidationDictionary());
Or even let the validation dictionary be injected as defined in the blogpost.

Is it possible to remove an existing registration from Autofac container builder?

Something along those lines:
builder.RegisterType<MyType>().As<IType>();
builder.RegisterType<MyType2>().As<IType>();
builder.DeRegisterType<MyType>().As<IType>()
var container = builder.Build();
var types = container.Resolve<IEnumerable<IType>>();
Assert.IsTrue(types.Count == 1);
Assert.IsTrue(types[0].GetType == typeof(MyType2));
Scenario: I go through bunch of assemblies and as I go I register types but I want to
make sure that I have only one implementation of a given type. I need to do this before I create the container. I could track that on my own but it would be nice if Autofac could help me a bit.

This cannot be done directly using the ContainerBuilder, unless you start over with a new one. Mind you, having first built a container you should be able to construct a new container filtering away unwanted types and reusing the registrations from the first container. Like this:
...
var container = builder.Build();
builder = new ContainerBuilder();
var components = container.ComponentRegistry.Registrations
.Where(cr => cr.Activator.LimitType != typeof(LifetimeScope))
.Where(cr => cr.Activator.LimitType != typeof(MyType));
foreach (var c in components)
{
builder.RegisterComponent(c);
}
foreach (var source in container.ComponentRegistry.Sources)
{
cb.RegisterSource(source);
}
container = builder.Build();
This is hardly very elegant but it works. Now, if you could elaborate on why you want to do this, perhaps there is a better way.

Peter L.'s probably got the most straightforward option.
To get around the problem altogether, can you modify the way you're discovering components to filter them in advance of registration? It does seem like there must be an approach that gets around this... It also might be a challenge further down the track to work out which components to keep vs. which to remove.
A more involved approach is to override IEnumerable support to filter out the the things you don't want. I.e. copy and modify this code to create a FilteredCollectionSource that excludes the components you don't want.
var elements = c.ComponentRegistry.RegistrationsFor(elementTypeService);
would become:
var elements = c.ComponentRegistry.RegistrationsFor(elementTypeService)
.Where(reg => /* not a duplicate */);
If you add your FilteredCollectionSource to the builder using RegisterSource() it will should get used instead of the built-in one.