Aspect Oriented Programing (AOP) solutions for C# (.Net) and their features [closed]

Question

I would like to ask for 3 information here:

1. There is no integrated solution for Aspect Oriented Programing (AOP) in C# (.Net) from Microsoft is that correct ? Is there any such solution under development or planned ?

2. What solutions are there that allow Aspect Oriented Programing (AOP) to be used in C# (.Net) ? What are they advantages/disadvantages ? I haven't find any comprihensive list that would contain all avatable options and some information for me to decide which is the one to use. The closest is this list.

3. What is (in your opinion) the best AOP solution for C#(.Net) considering following criteria:

   1. it schould work similar to AspectJ and has similar syntax
   2. simplicity of use: no XML configuration should be needed - just write some regular classes, some aspect classes and compile to weave it all together, then run.
   3. should include all features of AspectJ. Support for generics.
   4. solution should be stable, widely used and mainteined.
   5. should offer weaving of binaries (so could be used ) or C# source code.
   6. GUI tool for visualising (or even better - plugin to VS) is an advantage.

I think that if something fullfils most of criteria in 3. then it is a candidate for a generaly used solution. And I cannot find anywhere if some of existing solutions fits to my needs.

Answer 1

As Adam Rackis points out, Post# is the way to go, it is as close you will get to AspectJ on the .NET platform.

Main differences is obviously that AspecJ has language support for aspects while Post# is a post compile weaver for .NET assemblies. (thus no language integration)

However, Post# can use join points such as field access, try catch blocks, both calls and functions (that is, caller and callee)

1. No not even close, AspectJ is a language, Post# can use custom pointcuts but the most common is to use attributes to decorate methods to be pointcutted(eh..grammar?)

2. check

3. everything but language support

4. check

5. check - it is a post compile weaver

6. limited, the weaver will generate intellisense information and show what methods have been affected

If you want a .NET language that supports aspects, check out http://aspectsharpcomp.sourceforge.net/samples.htm

Regarding different approaches, there are a few:

1. Post compile weaving , this is what Post# does. It simply mangles the .NET assembly and injects the aspect code.

2. Real Proxy / MarshallByRefObject. Based on remoting infrastructure. Requires your classes to inherit from a base class. Extremely bad performance and no "self interception"

3. Dynamic Proxy. This is what my old library NAspect used. you use a factory to create a subclass of the type on which you want to apply aspects. The subclass will add mixin code using interfaces and override virtual methods and inject interceptor code.

4. Source code weaving. As the name implies, it transforms your source code before compilation.

[edit] I forgot to add this one to the list:

5. Interface proxies Similar to Dynamic Proxy, but instead of applying the interception code to a subclass, the interception code is added to a runtime generated interface proxy. That is, you get an object that implements a given interface, this object then delegates each call to any of the interface methods first to the AOP interception code and then it delegates the call to the real object. That is, you have two objects at play here, the proxy and the subject(your real object).

Client -> Interface Proxy -> AOP interception -> Target/Subject

This is AFAIK what Spring does.

1) and 3) are the most common. They both have pros and cons:

Post Compilation:

Pros:

• Can point cut pretty much everything, static , sealed, private
• Objects can still be created using "new"

Cons:

• Can not apply aspects based on context, that is , if a type is affected, it will be affected for the entire application.

• Pointcutting private, static, sealed constructs may lead to confusion since it breaks fundamental OO rules.

Dynamic Proxy:

Pros:

• Contextual, one typ can have different aspects applied based on context.

• Easy to use, no configuration or build steps.

Cons:

• Limited pointcuts, only interface members and virtual members can be intercepted

• must use factory to create objects