In the 11th part of the Castle Dynamic Proxy tutorial, I mentioned that surprising behavior of additional interfaces in case of interface proxy with target is not considered a bug. Coincidently, just few days later a user started a thread on our discussion group regarding this issue.
After some discussion we decided to change that, so starting with version 2.2 (or now, if you’re using daily builds) this behavior is no longer true.
We aligned it with how interface proxy with target works. Actually, this (not real) part of code illustrates the new behavior. Let’s assume we’re calling a method on interface IFoo passed as additional interface to implement by proxy.
invocation.Target = proxy.Target as IFoo;
So now when the proxy target implements the interface, it gets set as target of the invocation. Otherwise we get null target.
As a side note, with this change, the proxy type is no longer tied to the type of its target, which opens a way for some caching optimizations we have planned.
The second change we did, was to remove possibility of this stack overflow. You get either null or proxy target as the invocation target, but since an interceptor could potentially set invocation target as the proxy, we detect that and throw InvalidOperationException in this case.
Also when the invocation proceeds to the call on target, and the target is null, you get the standard behavior of invocation without target, which is NotImplementedException, just the one you would get from all other kinds of proxies.