We Keep Coding

AOP Pre-compile time weaving?

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

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.

What your are looking for is pMixins. It's still in beta, but it does exactly what you are looking for: design-time weaving. AOP code is generated into a partial code-behind class so it's available at design-time.
So this means you can do this in one file and the compiler is happy, visual studio is happy, resharper is happy:
Define an interface:
public interface ISomeInterface
{
void SomeMethod();
}
Create an implementation of the interface (I call this a Mixin):
public class SomeInterfaceImplementation : ISomeInterface
{
public void SomeMethod()
{
//implementation
}
}
Define a Target file (which will consume the Mixin):
[pMixin(Mixin = typeof(SomeInterfaceImplementation))]
public partial class Target { }
Let's create a utility class that works with SomeInterface and SomeInterfaceImplementation:
public class Utility
{
public void DoSomeWorkOnSomeInterface(ISomeInterface obj)
{
obj.SomeMethod();
}
public void DoSomeWorkOnImplementation(SomeInterfaceImplementation obj)
{
obj.SomeMethod();
}
}
And now let's see it all work together:
class Program
{
private static void Main(string[] args)
{
//Call the mixed in method
new Target().SomeMethod();
//Target implements ISomeInterface is code-behind
new Utility().DoSomeWorkOnSomeInterface(new Target());
//Target has an implicit conversion operator to
//SomeInterfaceImplementation in code-behind
new Utility().DoSomeWorkOnImplementation(new Target());
}
}
The reason this works is because as soon as you save the file, the pMixins code generator immediately does design-time weaving and updates the code-behind file. It adds the SomeMethod directly to Target, updates Target's class definition to implement ISomeInterface and creates conversion operators.
Disclosure: I am on the pMixins development team.

In the case of PostSharp, you can access an interface introduced at post-compile-time by using the method Post.Cast, which is a kind of cast operator that is verified at post-compile-time. See http://doc.postsharp.net/postsharp-3.0/Content.aspx/PostSharp-3.0.chm/html/M_PostSharp_Post_Cast__2.htm for documentation.

Using Attributes to Call Methods

I have various individual methods which all need to perform the same functions before continuing on with their own implementation. Now I could implement these functions in each method, but I was wondering if there's a way to exploit attributes to do this? As a very simple example, all network calls have to check for a network connection.
public void GetPage(string url)
{
if(IsNetworkConnected())
...
else
...
}
This would work, but I'd have to call the IsNetworkConnected method for each method that uses the network and handle it individually. Instead, I'd like to do this
[NetworkCall]
public void GetPage(string url)
{
...
}
If the network is unavailable, an error method is called instead and GetPage is ignored, otherwise GetPage is invoked.
This sounds very much like Aspect Orientated Programming, but I don't want to implement an entire framework for a few calls. This is more of a learning exercise than an implementation one, so I was curious as to how something like this would be best implemented.

You can use PostSharp, it is aspect-oriented framework for .NET, it seems quite easy to use:
static void Main(string[] args)
{
Foo();
}
[IgnoreMethod(IsIgnored=true)]
public static void Foo()
{
Console.WriteLine("Executing Foo()...");
}
[Serializable]
public class IgnoreMethodAttribute : PostSharp.Aspects.MethodInterceptionAspect
{
public bool IsIgnored { get; set; }
public override void OnInvoke(PostSharp.Aspects.MethodInterceptionArgs args)
{
if (IsIgnored)
{
return;
}
base.OnInvoke(args);
}
}
Method-Level Aspects feature is available in the free edition: http://www.sharpcrafters.com/purchase/compare
Run-Time Performance:
Because PostSharp is a compiler technology, most of the expensive work is done at build time, so that applications start quickly and execute fast. When generating code, PostSharp takes the assumption that calling a virtual method or getting a static field is an expensive operation. Contrary to rumor, PostSharp does not use System.Reflection at run time.
http://www.sharpcrafters.com/postsharp/performance

I don't think you can do this with attributes only, because they are not executed by the runtime if you're not actively doing something with them. A lightweight approach would be Ninject with Interceptions extension, it is a framework, but a very thin one, and one you might already be using for DI anyway.
Another option, but a bit more involved, could be based on MEF, and then you can use attributes and do something during with them during activation.

You're right, it sounds a lot like AOP.
What you're after sounds like compile time weaving? I.e. the attribute is turned into additional code by the compiler.
You could look at how to implement this...
Generating additional code through a custom attribute
http://www.cs.columbia.edu/~eaddy/wicca/ &
http://www.sharpcrafters.com/aop.net/compiletime-weaving
all refer to tools and techniques for doing this.
Or you could use an AOP framework. IMHO, you should look at AOP frameworks.

C#: Wrapping methods in other methods

Is there a way to wrap methods in other methods transparently in C#? I want to achieve what is done by Moose's around functionality: http://search.cpan.org/perldoc?Moose::Manual::MethodModifiers
EDIT: And by transparent I mean without modifying the original method.

I think you're looking for what's termed Aspect Oriented Programming. There are many C# libraries to help with this. One is called PostSharp (The free version of PostSharp supports this functionality). Here is an example similar to the moose example. This creates a Trace Attribute which you can use on other methods to tack on this extra functionality:
[Serializable]
public class TraceAttribute : OnMethodBoundaryAspect
{
public override void OnEntry( MethodExecutionArgs args )
{
Trace.WriteLine("about to call method");
}
public override void OnExit(MethodExecutionArgs args)
{
Trace.WriteLine("just finished calling method");
}
}
You would add it to method "Foo" by placing the Trace attribute right before it:
[Trace]
public void Foo() { /* ... */ }
Now when Foo executes, the above OnEntry method will run before it, and OnExit will run right after.

Indeed, they're called "delegates" in .NET. See:
http://alexdresko.com/2010/07/25/using-idisposable-objects-responsibly-the-easy-way/
http://alexdresko.com/2010/07/27/using-delegates-to-eliminate-duplicate-code/
for help.

You can achieve the same effect by utilizing a dynamic proxy. An example is the Castle Dynamic Proxy.
Such frameworks leverage the C# reflection facilities to construct 'proxy' or 'wrapper' classes. So, keep that in mind. There is a certain amount of overhead because of this. Alternatively you can use frameworks that can create classes statically via code generation.

No, not the way it's done in Moose. You might want to look into some AOP library.

Some isolation libraries implement functionality that allows replacing calls to methods with "detours" or mock methods. You may be able to use the same functionality to implement the interception you are referring to. For more details, check the following:
Rhino Mocks stubs and mocks are only good for interfaces?
http://research.microsoft.com/en-us/projects/moles/
http://www.typemock.com/typemock-isolator-product3/

Modify C# Class method during execution

I'd like to override a class method without inheriting the base class because it'd take a lot of time and modifications and, therefore, more and more tests. It's like this:
class TestClass{
public void initialMethod(){
...
}
}
And somewhere on the code, I'd like to do something like this:
public testMethod()
{
return;
}
test(){
changeMethod(TestClass.initialMethod, testMethod);
}
And this changeMethod function would override the TestClass initialMethod so that it'd call testMethod instead.
Inheriting and overriding the method using normal practices is not an option, as this class A is a graphic component and, inhereting it (and changing it) would break lots of code.
Edit: We don't have the base code for the TestClass, so it's not an option to modify the code there defining the initialMethod as a delegate.
Edit 2: Since this is a graphical component, the designer added a lot of code automatically. If I were to inherit this code, I would have to replace all code added by the designer. That's why I wouldn't like to replace this component.

You need the Strategy pattern.
Main steps:
Create an interface with ie. Do() signature
Your initialMethod() should call a strategy.Do(), where strategy is type of your interface
Create a class that implements this interface. Do() is your testmethod now.
Inject into your main class an instance of this class
If the job it's not so big (let's say just a color replacement or something) then I agree with Jhonny D. Cano's solution with C# (anonymous)delegates.
Edit (after edit 2)
May - just as proof-of-concept - you should inherit the class and replace all references from base class to this new. Do this, and nothing else. If it works, you can think about the next steps (new methods or delegates etc.)
You need only a new checkout from your version control system, and if it maybe fails you can abandon it. It's worth trying.

Perhaps you can do it as a delegate.
class TestClass {
public Action myAction;
public void initialMethod(){
...
}
initialMethod
public TestClass() {
myAction = initialMethod;
}
}
and then on TestMethod
public testMethod()
{
return;
}
test() {
testClassInstance.myAction = testMethod;
}

I think your best bet might be to use a AOP framework like LinFu. There's a codeproject article explaining it:
Introducing LinFu, Part VI: LinFu.AOP – Pervasive Method Interception and Replacement for Sealed Types in Any .NET Language

If 'TestClass' is something you defined, you could replace the 'initialMethod' definition with a property and delegate which can then be set to any method with a given signature. (Even anonymous ones.)
class TestClass {
Action _myMethod;
Action MyMethod {
get { return _myMethod; }
set { _myMethod = value; }
}
var tc = new TestClass()
tc.MyMethod = () -> Console.WriteLine("Hello World!");
tc.MyMethod()
The above code is untested.

The short and simple answer is: if you can't adjust the base TestClass code, no, there's no way you can modify the class to replace a method by another. Once we started doing stuff like that, we'd be in a completely different kind of language, like JavaScript.
The longer answer is: it depends on who is calling the replaced method.
If it's other classes, see if you can't implement a Proxy in between them and the unmodifiable concrete class. Whether this is doable depends on whether that class implements interfaces, or is its own interface.
If it's the class itself, then your only option is to decompile and modify the class, at design time using Reflector (or equivalent tools), or at runtime using Reflection.Emit. However, you'd have to be hurting pretty badly to go this route, as it's sure to be painful and brittle.
Unfortunately you still haven't explained what you are trying do and why. Replacing methods on the go is powerful stuff in the languages that permit it directly... There might be mocking libraries that can be twisted sufficiently far to do the reflection stuff, but then you'd be skating on thin ice.

If you don't have the code use Extension Methods.
public void doSmth(this objectYOUWANT arg)
{
//Do Something
}
Here you use the principle Closed for Modification Open for Extension.
This will add functionality to the library you don't have the source code. It's very clean to do it this way.
Edition:
In FrameWork 3.5 there is something new called Extension Methods. These kind of methods adds functionality to a closed Assembly letting you Extend in functionality a closed dll/assembly.
To use this for example you have a dll that you import, that is called Graphics.dll (you have the reference on your project)
First of all you shoud create a new static class called for example Extension:
public static class Extensions
{
}
Second, you want to add extra functionality to a class contained in Graphics.dll named ChartGraph. You will do this:
public static class Extensions
{
public static void draw(this ChartGraph g)
{
// DO SOMETHING
}
}
Third, when you instantiate a new object from the graphics.dll you now will have the new method you have created:
ChartGraph myG = new ChartGraph();
myG.draw();
As you can see there you have added new functionality without much effort without recompiling the dll, this is good if you don't have the source code.

Is there a way in .NET to have a method called automatically after another method has been invoked but before it is entered

What I am looking for is a way to call a method after another method has been invoked but before it is entered. Example:
public class Test {
public void Tracer ( ... )
{
}
public int SomeFunction( string str )
{
return 0;
}
public void TestFun()
{
SomeFunction( "" );
}
}
In the example above I would like to have Tracer() called after SomeFunction() has been invoked by TestFun() but before SomeFunction() is entered. I'd also like to get reflection data on SomeFunction().
I found something interesting in everyone's answers. The best answer to the question is to use Castle's DynamicProxy; however, this is not that I'm going to use to solve my problem because it requires adding a library to my project. I have only a few methods that I need to "trace" so I've chosen to go with a modified "core" methodology mixed with the way Dynamic Proxy is implemented. I explain this in my answer to my own question below.
Just as a note I'm going to be looking into AOP and the ContextBoundObject class for some other applications.

You can use a dynamic proxy (Castle's DynamicProxy for example) to intercept the call, run whatever code you wish, and then either invoke your method or not, depending on your needs.

Use a *Core method:
public int SomeFunction(string str)
{
Tracer();
return SomeFunctionCore(str);
}
private int SomeFunctionCore(string str)
{
return 0;
}
A number of the .NET APIs use this (lots do in WPF).

Use delegates!
delegate void SomeFunctionDelegate(string s);
void Start()
{
TraceAndThenCallMethod(SomeFunction, "hoho");
}
void SomeFunction(string str)
{
//Do stuff with str
}
void TraceAndThenCallMethod(SomeFunctionDelegate sfd, string parameter)
{
Trace();
sfd(parameter);
}

You want to look into Aspect Oriented Programming. Here's a page I found for AOP in .NET: http://www.postsharp.org/aop.net/
Aspect Oriented Programming involves separating out "crosscutting concerns" from code. One example of this is logging - logging exists (hopefully) across all of your code. Should these methods all really need to know about logging? Maybe not. AOP is the study of separating these concerns from the code they deal with, and injecting them back in, either at compile-time or run-time. The link I posted contains links to several tools that can be used for both compile-time and run-time AOP.

.NET has a class called ContextBoundObject that you can use to setup message sinks to do call interception as long as you don't mind deriving from a base class this will give you what you are looking for without taking an library dependency.

You would have to use some form of AOP framework like SpringFramework.NET to do that.

If you need to do this on large scale (i.e. for every function in a program) and you don't want to hugely alter the source, you might look into using the .NET Profiling API. Its a little hairy to use since you have to build free-threaded COM objects to do so, but it gives you an enormous amount of control over the execution of the program.

This is the solution I've choosen to solve my problem. Since there is no automatic (attribute like) way to make this work I feel it is the least obtrusive and allows the functionality to be turned on and off by choosing what class get instantiated. Please note that this is not the best answer to my question but it is the better answer for my particular situation.
What's going on is that we're simply deriving a second class that sometimes or always be instantiated in place of its parent. The methods that we want to trace (or otherwise track) are declared virtual and reimplemented in the derived class to perform whatever actions we want to trace and then the function is called in the parent class.
public class TestClass {
public virtual void int SomeFunction( string /*str*/ )
{
return 0;
}
public void TestFun()
{
SomeFunction( "" );
}
}
public class TestClassTracer : TestClass {
public override void int SomeFunction( string str )
{
// do something
return base.SomeFunction( str );
}
}