Castle Windsor and same service registered from signed assemblies with multiple versions

Viewed 45

I have an application which loads different versions of strongly signed assembly at the same time. Classes in each assembly become scanned and installed via WindsorInstaller after assembly load. I have an IFoo interface which wasnt changed between versions but the .net type name differs because of strong signing.

I am doing the registration like this:

public class WindsorInstaller : IWindsorInstaller
{
    public void Install(IWindsorContainer container, IConfigurationStore store)
    {
        container.Register(
            Component.For<IFoo>()
            .ImplementedBy<Foo>()
            .IsDefault()
            .Named(Guid.NewGuid().ToString())
            .LifestyleSingleton());
    }
}

So after both assemblies loaded I see multiple registrations to my IFoo service:

  • IFoo type (assembly version: 1.0.0.0) registration with Foo (assembly version 1.0.0.0) implementation, and
  • IFoo type (assembly version: 2.0.0.0) registration with Foo (assembly version 2.0.0.0) implementation

That seems to be okay at the moment.

Because of legacy code I should live with servicelocator pattern in some places, that's why I need to use Resolve(). But when I try to container.Resolve<IFoo>() in code running in the assembly 2.0.0.0 (so IFoo refers to 2.0.0.0 version) I receive the 1.0.0.0 version (because that was loaded first?) and right after an InvalidCastException when I try to assign the received instance to my variable which was awaiting a IFoo 2.0.0.0 object :(

I was walking through google and Windsor docs and do not understand why is this happening to me. The registration based on type which is clearly differs (just in version number, but that should be enough). I see the different registrations (in VS's quick view on container). Why the Resolve call is returning the "bad" instance?

Assuming that I didnt made anything wrong just it should not work in the way I expected it is clear that with the use of some of Windsor extension points I can achieve this functionality. I made some efforts about this (I tried to implement INamingSubsystem, IHandler, IDependencyResolver, ISubDependencyResolver, subscribing to DependencyResolving event (maybe I misstyped some of these here)) but without any success: no hooks found which allow me e.g. to select the appropriate IHandler from registered ones on Resolve() call. All of these seems to be used during initialization phase, not "runtime" during ad-hoc resolving.

But I am still sure that with one or appropriate combination of more extension points above the problem is solvable. Any guidenance would be appreciated :)

0 Answers
Related