Krzysztof pointed me to his post Castle Dynamic Proxy FAQ: why there’s no “class proxy with target” why the dynamic decorator is not part of Castles’s DynamicProxy implementation yet.

Looking at the code one realizes that the real problem is, that IsAdult() is not virtual. That’s why the decorator is not able to intercept and redirect that call to the target. There is no way around it – that is a real bug and it does show why a class proxy with a target is indeed dangerous. Thanks for pointing it out to me, Krzysztof!

The question we have to ask now is: If we refuse to generate the proxy, if any member more visible than protected is non-virtual, would that get rid of the bug? I would argue that it will, since the proxy will now be able to redirect the call to the target and everything works out fine. Or am I again missing something?