Castle Windsor resolve ienumerable and name

To fix this issue In my project I need to use simultaneously Castle.Windsor and Moq dlls. Windsor requires Castle.Core also to be referenced in the project. , Problem can be solved using assembly binding - App.config:

<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
  <dependentAssembly>
    <assemblyIdentity name="Castle.Core" publicKeyToken="407dd0808d44fbdc" />
    <bindingRedirect oldVersion="1.0.0.0-2.5.0.0" newVersion="2.5.1.0" />
  </dependentAssembly>
</assemblyBinding>

I hope this helps . You can register the 2 implementation with different names and then can pass the name while calling Resolve method. http://castleproject.org/container/documentation/trunk/manual/windsortypedocs/Generated_IWindsorContainer.html#IWindsorContainer_Methods5
Check this section in windsor docs

it fixes the issue Okay, I think I've found a possible solution, partly using the approach detailed here which shows how it is possible to register Func<>s with Windsor.
First, I register a delegate (Func<>) that uses the container to resolve by name:-

Container.Register(Component.For<Func<string, IHubProxy>>()
                   .Instance(name => Container.Resolve<IHubProxy>(name))
                   .LifestyleSingleton());

container.Register(Component.For<IHubProxy>()
               .UsingFactoryMethod((kernel, context) => hubConnection.CreateHubProxy("FooHub"))
               .LifestyleSingleton()
               .Named("FooHub"));
container.Register(Component.For<IHubProxy>()
               .UsingFactoryMethod((kernel, context) => hubConnection.CreateHubProxy("BarHub"))
               .LifestyleSingleton()
               .Named("BarHub"));

public class SomeClass
{
    private IHubProxy _fooHub;
    private IHubProxy _barHub;

    public SomeClass(Func<string, IHubProxy> hubProxyFactory)
    {
        _fooHub = hubProxyFactory("FooHub");
        _barHub = hubProxyFactory("BarHub");
    }
}

wish of those help How much time it takes to resolve an object graph depends on a lot of factors, such as:
The size of the object graph The registered lifestyles of components and the location of those lifestyles in the graph (obviously if the root object is a singleton, resolving is really fast) The amount of work you do in your constructors

Container       |  ms.
----------------+-----
Simple Injector | 0.01
StructureMap    | 0.50
Autofac         | 0.77
Unity           | 1.04
Castle Windsor  | 3.96
Ninject         | 5.03

seems to work fine Rather than returning a null reference (as you say in your comment), I'd instead return a null service implementation. In other words, an implementation that is a no-op or just a passthrough. This way the class consuming the service doesn't need to add in any logic that it really should not know anything about (i.e. whether or not the service is valid to use in a given situation).
To do this, you can just use the UsingFactoryMethod functionality to make the decision of which service to return at runtime. Taking the first registration that you want to be conditional:

// The URL for this service can be configured during runtime. 
// If it is null or empty it should not be resolved.
container.Register(Component.For<ITestService>()
    .UsingFactoryMethod((kernel, context) => 
    {
        if (!string.IsNullOrEmpty(SiteInformation.PublishUrl))
            return ServiceFactory.CreateService<ITestService>(
                SiteInformation.PublishUrl));
        return kernel.Resolve<INullTestService>();
    })
    .Named(PublicationServiceComponent)
    .LifeStyle.Transient);