I recently co-authored an article with Gael Fraiteur (creator of PostSharp) on how AOP frameworks such as PostSharp can be used to automate the implementation of common design patterns in .Net.
The article is now available to view on the InfoQ website here. A more offline friendly PDF version is also available here and from PostSharp’s brand new site.
Hope you enjoy what we have to say on the topic, and please don’t hesitate to give us your feedbacks!
Whilst searching for an elegant solution to apply string interning across a large number of classes (we’re talking about hundreds of classes here..) it dawned on me that I can achieve this with ease using PostSharp’s LocationInterceptionAspect. All I needed was something along the lines of:
You can apply this attribute to a class or even a whole assembly and it’ll ensure every piece of string constructed is interned, including string properties and fields defined by its subclass, which is exactly what I was after.
For example, take this trivial piece of code:
If you inspect the compiled code for the Base class in ILSpy you will see something along the lines of:
notice how the setter for BaseStringProperty has been modified to invoke the OnSetValue method defined in our aspect above as opposed to the setter method. In this case, it’ll call the String.Intern method to retrieve a reference to an interned instance of the string and set the property to that reference.
For more details on PostSharp’s interception aspects, I recommend reading Dustin Davis’s excellent posts on the topic:
PostSharp Principles: Day 7 Interception Aspects – Part 1
PostSharp Principles: Day 8 Interception Aspects – Part 2
As we’ve specified the multicast inheritance behaviour to multicast the attribute to members of the children of the original element, the string properties defined in both A and B classes are also subject to the same string interning treatment without us having to explicitly apply the InternAttribute on them:
What’s more, this attribute also works with F# types too, including record and discriminated unions types. Take for instance:
If you look at the generated C# code for the discriminated union type, the internal MyDuType.CaseB type would look something like the following:
notice how the two internal item1 and item2 properties’s setter methods have been modified in much the same way as the C# examples above? The public Item1 and Item2 properties are read-only and get their values from the internal properties instead.
Indeed, when a new instance of the CaseB type is constructed, it is the internal properties whose values are initialized:
Finally, let’s look at the record type, which interestingly also defines a non-string field:
because we have specified that the InternAttribute should only be applied to properties or fields of type string (via the CompileTimeValidate method which is executed as part of the post-compilation weaving process as opposed to runtime), so the internal representation of the Age field is left unaltered.
The Name field, however, being of string type, was subject to the same transformation as all our other examples.
I hope this little attribute can prove to be useful to you too, it has certainly saved me from an unbearable amount of grunt work!
NOTE: if you’re unfamiliar with how PostSharp works under the hood, I highly recommend that you check out Dustin Davis’ excellent PostSharp Principles series of blog posts here.
The new async/await keywords in C# are pretty awesome, and makes life an awful lot easier when writing asynchronous and non-blocking IO code. However, for those of us who are using frameworks such as PostSharp to deal with cross-cutting concerns we now face a new challenge – the aspects which we have come to rely upon no longer works the way we expect them to when applied on async methods (which returns void, Task or Task<T>), as can be seen from the examples below:
So what’s wrong here?
If you take a look at the code from the above example using a decompiler such as JetBrain’s DotPeek, you’ll see that the normal synchronous version of Foo looks something along the line of:
As you can see, the weaved code include calls to the OnEntry, OnSuccess and OnException methods provided by the OnMethodBoundaryAspect class, so everything is as expected here.
For FooAsync however, the picture is a little more complicated:
Turns out the C# compiler rewrites async methods into a state machine which means that although the OnSuccess and OnException hooks are still in place, they’re not telling us when the body of the method succeeds or fails but instead, when the state machine creation has succeeded or failed!
Pretty big bummer, eh?
One way (and the best way I can think of for now) to get around this is to have a special aspect which works with methods that return Task or Task<T> and hook up continuations to be executed after the returned tasks had finished. Something similar to the below will do for the on method boundary aspect:
And then you can create a TraceAsync attribute that works for async methods:
As you can see from the output above, our new OnTaskFinished, OnTaskFaulted and OnTaskCompletion hooks are correctly executed after the task returned by the async method had finished, faulted due to exception or ran to completion!
The same approach can also be applied to other built-in aspects such as the MethodInterceptionAspect class.
However, there are a two things you should consider first before jumping into the workaround proposed above.
1. if you look at the output from the previous example carefully, you’ll see that the line “FooAsync finished” came AFTER “Entering Boo” even though from the test code we have awaited the completion of FooAsync before calling Boo. This is because the continuations are executed asynchronously.
If this behaviour is not desirable to you, there is a very simple fix. Back in the OnAsyncMethodBoundAspect class we defined above, simply add TaskContinuationOptions.ExecuteSynchronously to each of the continuations:
2. the proposed solution still wouldn’t work with async methods that return void simply because there are no returned Task/Task<T> objects to hook up continuations with. In general though, you should avoid having async void methods as much as possible because they introduce some pitfalls which you really wouldn’t want to find yourself in! I’ve discussed the problem with aysnc void (and some potential workarounds) in a previous post here.
I hope this post proves useful to you, and happy PostSharp’ng! I hear some big things are coming in this space 
I gave a talk about Aspect Oriented Programming at this year’s DDD South West, the slides is available on SlideShare:
The source code I used can be found here.
A big thank you to the guys for making DDD South West the great event it was and for having me on-board this year, I had plenty of fun! Hope everyone who made it to my session enjoyed what I had to say and are thinking about using AOP in their projects.
If you couldn’t come to the session I’ll be talking to VBUG Bristol on the 13th June so hope to see you then!
