Castle Windsor intercept method call from within the class

Question

We have components registrations in Castle Windsor container like so

void RegisterComponent() {
    var component = Compon         


        

Answer 1

For interception to work on MethodA1 when invoked from MethodA2 you need to be using inheritance based interception (it's because you are using this reference to make the invocation).

To make inheritance based interception possible first you need to make MethodA1 and MethodA2 virtual.

Then you can make container registration like this:

container.Register(Component.For<ServiceA>().Interceptors<SomeInterceptor>());
container.Register(Component.For<IService>().UsingFactoryMethod(c => c.Resolve<ServiceA>()));

First register your service as itself applying interceptors (this will add inheritance based interception over the service). Then you can register the interface which will use service registered earlier.

Answer 2

@NikolayKondratyev I've looked into https://github.com/castleproject/Windsor/blob/master/src/Castle.Windsor/Windsor/Proxy/DefaultProxyFactory.cs#L110 and I've done the registration the easy way: container.Register(Classes.FromThisAssembly().BasedOn(typeof(IRepositoryBase<,>)) .WithServiceAllInterfaces().WithServiceSelf() .LifestyleTransient());

Note .WithServiceSelf() call, this actually switches class-based proxying

Answer 3

We use CreateClassProxy method to create the proxy for the service as it was proposed in an answer to the question Castle Dynamic Proxy not intercepting method calls when invoked from within the class. Then we register the obtained proxy as an implementation for the interface. So our custom RegisterComponent method looks like this

private void RegisterComponent<TInterface, TImplementation>()
    where TInterface : class 
    where TImplementation : class, TInterface
{
    var proxyType = new ProxyGenerator().CreateClassProxy<TImplementation>().GetType();
    Container.Register(Component.For<TInterface>().ImplementedBy(proxyType));
}

The full component registration is

Container = new WindsorContainer();
Container.Kernel.Resolver.AddSubResolver(new CollectionResolver(Container.Kernel));

// Interceptor
Container.Register(Component.For<IInterceptor>().ImplementedBy<SomeInterceptor>().LifestyleTransient());

// Component registrations
RegisterComponent<ISomeService, SomeService>();

And, of course, all methods you need to intercept should be virtual since inheritance based proxy is used.

However a drawback of this solution is that you could not use constructor injection when creating a proxy object. Notice that you are creating "dummy" proxy object with new operator only to get a type of the proxy. Therefore you are unable to use constructor injection only when constructing a dummy proxy, but when you resolve your service via container, injection would work just fine. So this drawback is critical only for components with construction logic being more complex than just assigment of dependencies. If you need only dependency assigments you can try to resolve all dependencies from container manually before creating dummy proxy

private object[] ResolveConstructorParameters<TType>()
{
    return typeof(TType).GetConstructors()
                        .Single(c => c.IsPublic)
                        .GetParameters()
                        .Select(p => _container.Resolve(p.ParameterType))
                        .ToArray();
}

and then RegisterComponent would become

private void RegisterComponent<TInterface, TImplementation>()
    where TInterface : class
    where TImplementation : class, TInterface
{
    var constructorParameters = ResolveConstructorParameters<TImplementation>();
    var proxyType = new ProxyGenerator().CreateClassProxy(typeof(TImplementation), constructorParameters).GetType();
    _container.Register(Component.For<TInterface>().ImplementedBy(proxyType));
}

You can also just fill arguments with null.

Answer 4

Change your registration to the following and Windsor should switch to class proxies - i.e. using inheritance for interception, instead of composition.

void RegisterComponent<TInterface, TImplementation>() {
    container.Register(Component.For<TInterface,TImplementation>().ImplementedBy<TImplementation>().Interceptors<SomeInterceptor>());
}

Answer 5

I know this is an old thread, but I just came across it while getting Castle interceptors working in Blazor WASM (which they actually do, but beware...Mono can't seem to support proxying any class that has any generic methods...).

Anyway, to get around this issue in my case, I simply injected the container into my class, and in the method that needed to call a "sibling method" via this I simply resolved a fresh instance of my interface and called the method on that. It won't work for scenarios with shared context/transient states, but the interceptor indeed does its thing.

In Blazor's client WASM app's Program.cs:

public static async Task Main(string[] args)
{
    WebAssemblyHostBuilder builder = WebAssemblyHostBuilder.CreateDefault(args);

    ...

    builder.ConfigureContainer<IWindsorContainer>(new WindsorServiceProviderFactory(), container =>
    {
        container.Register(Component.For<IInterceptor>()
                                    .ImplementedBy<BlazorInterceptor>()
                                    .Named("BlazorInterceptor").LifestyleTransient());
    });

    ...

    builder.Services.AddScoped<IService, Service>();
    
    ...

    await builder.Build().RunAsync();
}

Example service and interface implementation:

public Interface IService
{
    MethodA(int arg);
    MethodB(int arg);
}

[Interceptor("BlazorInterceptor")]
public class Service : IService
{
    private readonly IServiceProvider _container;

    public Service(IServiceProvider container)
    {
        this._container = container;
    }

    public MethodA(int arg)
    {
        IService service = this._container.GetRequiredService<IService>();
        service.MethodB(arg);
    }

    public MethodB(int arg)
    {
        //should be intercepted...just in a different instance of the service unless you're using singletons...
    }
}

Pros: Doesn't require virtualizing methods or complicating your DI configuration. Cons: Kind of gross (useful for stateless repositories, but would probably give something like EF a heart attack).