A couple of times I've been discussing adding AOP features to C# or the CLR. Most of thees discussions has been with members of the C# team but also with Ed formerly on the PAG team.

The basis of Microsoft's objection to Aspects has always been that injecting behavior based on some kind of configuration is confusing and does not give a clear picture of what the result of the code you are looking at would be. Since aspects could or could not be applied, there is no way for you anticipate the exact behavior. This is a fair point to make, and very real.

A similar point was made about polymorphism and virtual methods back in the days, where allowing overrides of methods could dramatically change how the code behaved and thus not make it clear exactly what happens when calling that method.

Today we just don't care anymore, we have even named the "not knowing" with a pattern name; "Template Method".

Much like polymorphism has come to play a very important role in the design and implementation of software today, I feel that aspects are moving to wards filling an equally important role. The idea of reusing cross cutting concerns and by configuration apply them to different parts of my software is very appealing.

This will allow me, for example, to create a centralized caching mechanism which I could choose to apply or not apply to certain methods by configuration. The code in the method is itself not interested in whiter or not it gets cached but I would get the ability to apply it where I see fit, without touching the code. Taking the caching example further I could have some methods utilizing the cache, while others would flush it. Like GetOrder / UpdateOrder. Get might be cached and Update might flush that cache (now let's not get into the pitfalls with caching, this is about cross cutting concerns).

For me aspects is the natural evolution of object orientation and the single responsibility principle. It allows me to really separate my software into reusable parts where I can add and remove behaviors as I go.

Microsoft's story around this is interesting. Aspects really need a good mechanism for interception. Where it has to be possible to intercept method calls and react to them before or after they are called. Going back to the argument that "There will be hidden code that executes", let's look back in history for a while.

When Microsoft built MTS and COM+ they realized that to be able to make any method transactional they had to have some kind of mechanism to intercept a method call, start the transaction and then execute the method. How did they implement this? They used proxies  that could intercept just about anything and apply CROSS CUTTING CONCERNS (like transactions) on the COM+/MTS objects. So product teams at Microsoft has successfully walked the path of interception. In one sense COM+/MTS used the idea behind aspects to accomplish what they had in mind.

Remoting had a similar story, where our objects got intercepted by the remoting framework and funky stuff happens by itself in the call chain (where we actually could add our own interceptions).

Building frameworks and containers is one thing where aspects really excel. The frameworks can apply their functionality on top of what ever the user of the framework is building and the user don't have to think to much about it. One such example is dirty tracking of the objects. Using aspects and applying dirty tracking to every setter, we don't have to write code like this:

public string Name {
 get { ... }
        set {
            _name = value;
     FlagDirty("Name");
        }
}

Over and over and over and over again in our code. It could simply be applied by the framework as an aspect that stated "When a property gets set, mark that object/property dirty".

There is numerous of other scenarios where intercepting and adding behavior is important.

Now building some advanced frameworks of their own where they will apply functionality on users code, Microsoft have come to realize that having points of interception where stuff can be added is very useful. The remoting and COM+ approach proves that.

Since aspects are a plague, they now have come up with yet another idea of how to apply these interception points. They called them "partial methods".

Partial methods will allow their framework (which relies heavily on generating code instead of having the code centralized and applied in runtime) to put in interception points in the code, that may or may not be applied.

Using partial methods the dirty example might look like this:

public partial class Person {

   public partial void SetDirty(string propertyName);

   public string Name {
     get { ... }
     set {
         _name = value;
         SetDirty(propertyName);
     }
   }
}

Now if we do nothing, the compiler will simply remove that method call as if it was not there. If on the other hand we add an implementation:

public partial class Person {
  public partial void SetDirty(string propertyName) {
     IsDirty=true;
  }

}

The method now instead gets called.

Ayende (http://www.ayende.com/Blog/) has talked about this and Matt Warren (http://blogs.msdn.com/mattwar/) answered in the comments that "this feature is added to allow code generators to expose interception points".

So instead of creating a mechanism that would allow for interception so others had more support of building frameworks like remoting or containers like com+, they bloat the language with features to support their code generation tools. Now I might be out on a limb here but; WHY?

Creating features in the language to support a specific scenario seems like a waste of resources. If the instead put down resources on creating a generic way of doing interception, support a gadzillion more scenarios which the generator might not have thought of. I could apply interceptions to the generated code that would be special for my scenario, and by configuration at best.

The PAG team has made a real effort here though, they have created the Policy Injection framework which is kind of a V1 of an AOP framework from Microsoft. It relies on the same mechanism as Remoting does, which is kind of killing mosquito's with a bazooka.

What I would like to see from Microsoft though is not the ultimate AOP framework, but constructs in the CLR that would allow for others to build thees kind of frameworks or at the minimum not create constraints that makes it harder.

So, Microsoft, please consider adding support for interception scenarios so that we too can build framework and containers that do funky stuff and stop bloating the language with TOOL specific features.