About Enterprise Library
With the new release of the Enterprise Library of Microsoft patterns & practices team, it seems like AOP makes a great and sudden come back in the .NET community. The latest release comes indeed with the Policy Injection Application Block, which is a kind of AOP framework that allows to “inject” the other Enterprise Library application blocks (logging, exception handling, …) into user code, and using a configuration file.
The implementation use remoting proxies to intercept method calls and inject policies, which has the major drawbacks to:
- Be limited to methods derived from MarshalByRefObject or exposing their semantics on an interface.
- Require instances to be created through a factory.
This is a great opportunity to demonstrate how PostSharp can be used, not only to overcome these issues, but also to offer new benefits. Hopefully, the p&p team had this in mind when they designed this application block: the framework can be used even if we choose not to go through factories.
About PostSharp
PostSharp is a post-compiler for the .NET Framework. It modifies .NET assemblies after compilation. PostSharp works at MSIL level. PostSharp can be used as an Aspect Oriented Programming (AOP) framework, but it is only one possible use.
PostSharp Laos is a true AOP framework that does not require any knowledge of MSIL. Developers can react to “event” that happens in the code and can use the standard System.Reflection API.
Introducing PostSharp4EntLib
The first release of PostSharp4EntLib provides three custom attributes that ‘bind’ Policy Injection to user code.
The InjectPoliciesFromConfiguration custom attribute
This attribute can be applied to an assembly. It means that the policy injection settings will be completely processed at compile time. Here is how it is used:
[assembly: InjectPoliciesFromConfiguration("CompileTimePolicyInjection.config")]
This custom attribute processes matching rules specified in the configuration file and changes the affected methods so that applied policies are effectively invoked at runtime.
This custom attribute serves the scenarios where both matching rules and policies are known at compile time. Benefits are:
- Matching is performed at compile-time, so that runtime execution is faster.
- Policy Injection configuration does not have to be deployed.
- As with anything in PostSharp, remoting proxies and factories are not necessary.
The InjectPolicy custom attribute
This attribute indicates that a given policy should be injected to a method. The name of this policy should be known at compile-time, but not the content.
This custom attribute may be applied to methods:
[InjectPolicy("Exception Handling")]
public void Close()
{
…
}
The attribute may be multicasted to many methods using wildcards:
[assembly: InjectPolicy("Exception Handling", AttributeTargetTypes="MyProject.BusinessLayer.*")]
Benefits of this attribute are:
- There is no CPU-expensive runtime matching.
- In some scenarios, make it easier to specify which policies should apply to methods (more flexible than the ‘Tag’ approach of EntLib).
- As with anything in PostSharp, remoting proxies and factories are not necessary.
The Interceptable custom attribute
This custom attribute simply adds the code to make the method ‘interceptable’, i.e. to make it a possible target of policy injection, without the use of factories. Policies are matched and applied at runtime.
Like the InjectPolicy attribute, this one can be applied to methods, either directly either using multicasting:
[assembly: Interceptable("Exception Handling", AttributeTargetTypes="MyProject.BusinessLayer.*")]
The benefit is of course that policies can be injected on unchanged existing code:
- no need for factories,
- not limited to MarshalByRefObject,
- works also with static methods.
How does it work?
As I said in the beginning, PostSharp achieves this result by modifying the assembly after compilation. The best way to see how the code is modified is to use look at the modified code using Roeder’s Reflector.
Say we have the following user code (in C#):
public static void Transfer(BankAccount origin, BankAccount destination, decimal amount)
{
origin.Withdraw(amount);
destination.Deposit(amount);
}
We make this method interceptable by one of the three custom attributes described above. After compilation and post-processing by PostSharp, the method looks like that:
[DebuggerNonUserCode]
public static void Transfer(BankAccount origin, BankAccount destination, decimal amount)
{
Delegate delegate2 = new ~PostSharp~Laos~Implementation.~delegate~3(BankAccountProcess.~Transfer);
object[] arguments = new object[] { origin, destination, amount };
MethodInvocationEventArgs eventArgs = new MethodInvocationEventArgs(delegate2, arguments);
~PostSharp~Laos~Implementation.~aspect~9.OnInvocation(eventArgs);
}
The old method body has been moved to a new (private) method called ~Transfer.
The new implementation basically creates a delegate to the old implementation, create event arguments and call a OnInvocation method. This is where the PostSharp4EntLib code lays. Basically, this method invokes the EntLib pipeline of handlers.
The implementation of PostSharp4EntLib has two parts:
- A compile-time part whose principal role is to detect which methods needs to be ‘interceptable’, and adds kinds of ‘event handlers’ (OnMethodInvocation in our case) on these methods.
- A runtime part which is basically the implementation of the event handlers.
I repeat, PostSharp4EntLib does not generate MSIL instructions itself. It relies on PostSharp Laos, which defines this system of “code-driven event handlers” whose OnMethodInvocation is the only used here. Other “handlers” (called aspects or advices) are OnMethodBoundary, OnFieldAccess or OnException. They are not currently used but may be in the future of this project.
Waiting for a CodePlex project…
I would like to release this project on CodePlex but I am still waiting for Microsoft to upgrade their servers. Would you have any influence on the acceptance on my project… 
Before I get the CodePlex space, you can access the project from the PostSharp4EntLib Project Dashboard.
Many thanks to Olaf Conijn for its online support.
