AOP Pre-compile time weaving?

Question

I have been playing along with AOP for years, but didnt become 100% satisfied with the solutions. AOP Frameworks with runtime weaving, like Spring.AOP, cannot change the interface of a class. With post compile time Frameworks like Postsharp (anyone knows someone else ?) you can. Check this sample out, it adds INotifyPropertyChanged implementation to your class. -> http://www.postsharp.net/model/inotifypropertychanged

This AOP feature is really great, but you run in troubles very soon... If you want to access the new Interface within the hosting assembly, you cannot compile, because the interface is added AFTER compilation. so you get a "PropertyChanged is not defined"-error. So you have to ugly workaround this, by seperating the classes into another assembly, so you can use those AOP advantages. I remember, i ran into the same "Post compile time"-troubles using a T4-Template that generates source code, based on the reflected infos of a assembly. OK so post compile time is sometimes too late...

What i am looking for is a solution, where the source code of the class is parsed via a visual studio user defined tool, und then generates the code in a C# file, in a partial class. (so all AOP applied classes have to be partial)

So its kind of "Pre-Compile-Time AOP". This should definitly be possible, and could be done via using NRefactory as Code Parser. Furthermore, Visual Studio would like this much more, than a post-compile modification.

So this solution eliminates disadvantages of post compile time weavers. but does not give you all the features of AOP. But together with an AOP-Framework, this should be awsome.

Does anyone know a framework like this, or a discussion ?! what do you think ?

kind regards, thomas

Answer 1

since you and I have already been corresponding on using SNAP as a viable alternative, I thought I'd post a summary of our discussion here for the benefit of those who are looking for a similar solution.

In short, SNAP provides a runtime AOP framework that doesn't change your code in any way. There's no post-compile step, just runtime interception which is predictable and easy to use.