# re: 7 Approaches for AOP in .Net 7/2/2007 11:33 AM Stefan Wenig

I wrote an interception infrastructure using remoting proxies/ContextBoundObject a few years ago, and here's why I think it doesn't fly:
- You can't intercept calls on 'this' (actually, I found a way, but it involved native x86 assembler, native thread-static flags that decide whether to intercept or to do the actual call, broke the CLR promise that 'this' would never be a proxy, made it impossible for the debugger to step-into, and all in all was just insanely complex. I dropped it)
However, AOP is _very_ incomplete if you can only intercept method calls on object boundaries.
- The performance penality was a factor of about 1000 compared to plain virtual calls, although I removed the whole remoting infrastructure and worked with a plain transparent/real proxy pair. It still does involve remoting though. Now a plain call is cheap, and 1000 x cheap might not amount to much if you call a method that actually does stuff. Although that stuff is calling other intercepted methods, that is. So for a general purpose interception infrastructure this is far to heavy. I was very surprised when I recently learned that EntLib is going down this path...

Using the profiler API is probably the most fragile and unportable here. So this gives us a choice of either subclassing or weaving. I suspect the biggest problem with weaving is binary compatibility. I wonder how this is dealt with when weaving strong-named assemblies.

The major problems of sublcassing are:

- Does not work for non-virtual methods, like you said. Given the importance that AOP and interception are gaining, I think something should be done about it. I tried to talk to Eric Lippert about it, but unfortunately he sometimes just doesn't answer...
http://blogs.msdn.com/ericlippert/archive/2007/06/14/calling-static-methods-on-type-variables-is-illegal-part-one.aspx (second comment)

- Can't be used if objects are created with 'new'. Hey, we really need a way to overload 'new' (C#) or 'newobj' (IL)! Or at least some discipline to use factories for object creation. This is an area where code written by Microsoft (or generated by MS-tools) usually looks like it was built by amateurs. Really, this has to stop.

You could add that weaving gives you more power to hook right into the body of an existing method, but depending on your point of view, that is not necessarily an advantage. Subclassing constrains you to the interfaces that the author of a class defined, so your aspects should not break if that class changes (or anything derived from that class could break, so at least there is no new category of breaking changes that the author might not be aware of). I think even with AOP you should treat other people's methods as black boxes, unless you use AOP for patching.