[API Proposal]: Custom attribute for Pre-compile AOP

[wsq003]

Background and motivation

[MyCache(DurationSeconds = 5)]
public string GetUserName(int userID)
{
    //load from db
    return "Mike";
}

[MyPerfLog()]
public bool Login(string userName, string password)
{
    //check with db
    return true;
}

It is very annoying to add AOP to functions.
For now, you need to:
1, Create a custom Attribute
2, Create a custom Interceptor to handle your custom Attribute
3, Register your Interceptor at application startup

I think there would be a syntactic sugar that handling specific attribute.

API Proposal

[AttributeUsage(AttributeTargets.Method | AttributeTargets.Class)]
public abstract class AopAttribute : Attribute
{
	/// <summary>
	/// </summary>
	/// <returns>if execute the real Method or not</returns>
	public abstract bool BeforeMethod(MethodInfo info);
	public abstract void AfterMethod(ResultInfo result);

	public abstract Task<bool> BeforeMethodAsync(MethodInfo info);
	public abstract Task AfterMethodAsync(ResultInfo result);
}

This is a compile-time attribute, more or less like System.Diagnostics.ConditionalAttribute.
Compiler will generate proxy class to wrap the target functions.

API Usage

public class MyPerfLogAttribute : AopAttribute
{
	ILogger _logger;
	DateTime _begin;

	public MyPerfLogAttribute(ILogger logger)
	{
		_logger = logger;
	}

	public override bool BeforeMethod(MethodInfo info)
	{
		_begin = DateTime.Now;
		return true;
	}

	public override async Task<bool> BeforeMethodAsync(MethodInfo info)
	{
		_begin = DateTime.Now;
		await Task.CompletedTask;
		return true;
	}

	public override void AfterMethod(ResultInfo result)
	{
		var span = DateTime.Now - _begin;
		_logger.LogInformation($"use {span.TotalMilliseconds:0.00}");
	}

	public override async Task AfterMethodAsync(ResultInfo result)
	{
		var span = DateTime.Now - _begin;
		_logger.LogInformation($"use {span.TotalMilliseconds:0.00}");
		await Task.CompletedTask;
	}
}

[MyPerfLog()]
public bool Login(string userName, string password)
{
    //check with db
    return true;
}

Then the compiler will take care the rest.

Risks

1. Application Performance: should not be affected.
2. Compiler complexity: should be fine.
3. Extensibility: should be fine.
4. Applicability: AOP is a very common requirement. Such compiler supported pre-compile AOP attribute should be very sweet.

Alternative

1. A built-in interceptor can also do such things easily. A built-in interceptor will not need to change compiler, but will slow down the application startup speed. Application startup speed is important in this docker(container) era.

[acaly]

I think it's probably better to at least sketch how this should be implemented. For example, I can't figure out how async interceptor methods can be applied on sync methods.

Another problem is that this might be too complicated and specific to be a pure runtime feature. It might be better to propose that the runtime only exposes a more general API (for example, to raise an event that allows the program to modify the IL of a method while it is loaded), which the C# compiler can use to make this happen. Again, I think it is necessary to provide more information on how this should be designed and implemented.

I also want to remind you that C# team are known to have negative attitudes toward AOP. That's why there are so many third-party tools in this area.

[wsq003]

I think it's probably better to at least sketch how this should be implemented. For example, I can't figure out how async interceptor methods can be applied on sync methods.

I am not compiler expert. There is a Java IDE plugin called Lombok which can decorate Java code before real compile. I think that would be a good reference.

Sync methods use sync interceptor. Async method use async interceptor. This is why AopAttribute need both sync and async implementation.

Another problem is that this might be too complicated and specific to be a pure runtime feature. It might be better to propose that the runtime only exposes a more general API (for example, to raise an event that allows the program to modify the IL of a method while it is loaded), which the C# compiler can use to make this happen. Again, I think it is necessary to provide more information on how this should be designed and implemented.

I suppose this AopAttribute may be supported in code-gen module. There should be a code-gen module to handle different kinds of syntactic sugar before real compile.
I am not sure where code-gen belong to. Rumetime, compiler or somewhere else.

I also want to remind you that C# team are known to have negative attitudes toward AOP. That's why there are so many third-party tools in this area.

Yeah, more or less I know that. But AOP is a big area and have many types.
https://stackoverflow.com/questions/39448543/run-time-aop-vs-compile-time-aop
I believe Source code weaving should be sweet and will cause minimal side effect.

[davidfowl]

Why not use something like https://github.com/vescon/MethodBoundaryAspect.Fody

[wsq003]

Why not use something like https://github.com/vescon/MethodBoundaryAspect.Fody

Three reasons:

1. MethodBoundaryAspect.Fody do not have async version wrapper, while async is very import and common used today.
2. MethodBoundaryAspect.Fody use Binary weaving with certain draw back.
3. MethodBoundaryAspect.Fody has too few stars/forks, means it's maturity is not enough. I would prefer an official implementation which will be more promising.

Edited: MethodBoundaryAspect.Fody can support async method, but itself do not have async version.
Edited: MethodBoundaryAspect.Fody use Binary weaving not Reflection

[davidfowl]

I would prefer an official implementation which will be more promising.

I'm pretty sure we're not going to build AOP into the runtime. Everyone would prefer everything to be built into the runtime even though they are packages on nuget that can do similar things.

[davidfowl]

https://github.com/vescon/MethodBoundaryAspect.Fody#asynchronous-sample

https://github.com/vescon/MethodBoundaryAspect.Fody#asynchronous-sample

https://github.com/vescon/MethodBoundaryAspect.Fody#asynchronous-sample

Are you sure it uses reflection?

[wsq003]

I would prefer an official implementation which will be more promising.

I'm pretty sure we're not going to build AOP into the runtime. Everyone would prefer everything to be built into the runtime even though they are packages on nuget that can do similar things.

I agree that the runetime should not combine with dynamic-inject style AOP.

1. That will cause real action separated from source code. And such separation will make programmer confused.
2. Performance issue.

But some kine of Source code weaving may be acceptable.

[wsq003]

https://github.com/vescon/MethodBoundaryAspect.Fody#asynchronous-sample

https://github.com/vescon/MethodBoundaryAspect.Fody#asynchronous-sample

MethodBoundaryAspect.Fody can support async method, but the OnEntry do not have async version. This would cause sync-over-async if someone want to do some async job in OnEntry, which is very possible.

https://github.com/vescon/MethodBoundaryAspect.Fody#asynchronous-sample

Are you sure it uses reflection?

Sorry my bad, seems like it uses Binary weaving like PostSharp.

[acaly]

Another reason to avoid Fody related stuff is its strange License.

Actually I think the C# source generator can be a good replacement to Fody in many cases. For example, the async interception can be designed as:

//Ask the source generator to generate a method with name "YourPublicMethod"
[GenerateInterceptedMethod("YourPublicMethod")]
[Log] //Add anything you want as attributes here.
private async Task YourImplementation() //The name of this method is only used by the source generator.
{
  //Actual implementation.
}

Then the generator will generate:

public async Task YourPublicMethod()
{
    await Log.BeforeMethod(...);
    await YourImplementation();
    await Log.AfterMethod(...);
}

[wsq003]

Another reason to avoid Fody related stuff is its strange License.

Actually I think the C# source generator can be a good replacement to Fody in many cases. For example, the async interception can be designed as:

//Ask the source generator to generate a method with name "YourPublicMethod"
[GenerateInterceptedMethod("YourPublicMethod")]
[Log] //Add anything you want as attributes here.
private async Task YourImplementation() //The name of this method is only used by the source generator.
{
  //Actual implementation.
}

Then the generator will generate:

public async Task YourPublicMethod()
{
    await Log.BeforeMethod(...);
    await YourImplementation();
    await Log.AfterMethod(...);
}

Yes! Some kind of source code generator before real compile would be straightforward and elegant.

[acaly]

Yes! Some kind of source code generator before real compile would be straightforward and elegant.

Source generator is very versatile. The only issue is that it's still new and you probably have to write your own generator for your specific task, including something like this AOP feature.

[wsq003]

Yes! Some kind of source code generator before real compile would be straightforward and elegant.

Source generator is very versatile. The only issue is that it's still new and you probably have to write your own generator for your specific task, including something like this AOP feature.

This is why I proposal a abstract class AopAttribute: let built-in code-gen or compiler to do such souce code generator staff in a limited pre-designed way.
This would be super simple for programmer to understand and use.