We in the Microsoft .NET community are lucky: at critical moments, we are a few steps
behind the Java community. So we got C# and .NET after them, but we learned from
their mistakes, and got better language and platform. The same with AOP. AspectJ is widely used
over there, there is
plently of feedback, and PostSharp has been designed accordingly.

One of the questions engineers face when applying aspects to large software
is: how do you ensure aspects don't collide? This was a key design concern for
PostSharp 2.0; here I'll show how it's addressed. Be confident that this
feature puts PostSharp at the peek of all industrial aspect weavers, without
distinction of language.

Ordering Aspects

Let assume the following. We have two aspects: caching and authorization.
Obviously, we want authorization to be performed before caching.

I skip the code of the aspects. It's not the point here. But let see how we
define dependencies between aspects:

Aspects can provide a role. A role describes the
function of the aspect; represented as a unique string. The class
StandardRoles is a list of the most common aspect roles you would find
in business applications. To name a few of them: caching, security,
persistence, validation, observabiltity, exception handling, transaction
handling, and so on. We specify this using the custom attribute
ProvideAspectRole.

Aspects can define relationships to other aspects.
Here, the custom attribute AspectRoleDependency specify a depedency
to other aspects that provide a given role. The custom attribute on
AuthorizationAspect just means: this aspect should be before any aspect
providing caching.

Now, if you apply two aspects on the same method, they will be ordered as you
expect:

There are other ways than roles to match dependent aspects. For instance,
AspectTypeDependency allows you to specify an aspect type explicitely. All
dependency attributes are in namespace PostSharp.Aspects.Dependencies.

Expressing Aspect Conflicts

Let's take another scenario. I have a method, say ISecurable.IsUserInRole,
and I want to avoid at any price that this method gets cached.

Easy: we create an aspect NotCacheableAttribute with no logic at all
(the aspect does strictly nothing), and add a dependency:

Conflicting aspects on
"Dependencies.Entities.Organization/IsUserInRole([mscorlib]System.Security.Principal.IPrincipal
principal, string role) : bool": 'Dependencies.Aspects.NotCacheableAttribute'
cannot be used together with 'Before Dependencies.Aspects.CacheAttribute (3)'
because the second provides the role 'Caching'.

And this is exactly what we wanted!

Aspect Commutativity

You maybe remember commutativity from school. Multiplication is commutative
because 5*4 = 4*5; division is not. And you maybe even remember
function composition, which combines two functions in one: (f o g)(x) =
f(g(x)). Functions f and g are mutually commutative if
f o g = g o f. If you have done a little more maths, you know that
commutativity applies to differential operators, so we have (in good cases):
d/dx o d/dy = d/dy o d/dx. And if you have done much more maths, you are
even maybe an ace in Lie
algrebra, which I never understood.

Just as with functions and differential operators, if makes sense to talk of
commutativity with aspects.

Say we have two aspects on the same method: tracing and exception handling.
Does it matter if one aspect executes after the other? If you don't care, then
these aspects are said to commute (in other words, they are mutually
commutative). If not, you have to specify their ordering specifically.

If two aspects are not commutative but are not strongly ordered
(because you did not specify an ordering dependency), you will get a nice
warning at buid time:

Conflicting aspects on "Dependencies.Entities.Quote/GetQuoteDetailsHtml()
: string": transformations "Dependencies.Aspects.TraceAttribute" and
"Dependencies.Aspects.AuthorizationAttribute" are not commutative, but they are
not strongly ordered. Their order of execution is undeterministic.

You have two ways to get rid of this warning: either your order them strongly
by aspecifying an order dependency (see above), either you specify that both
aspects commute:

You may ask -- why to bother, anyway? Well, because every professional knows
how hard it is to troubleshoot non-deterministic issues, PostSharp 2.0 carefully
detects these situations and warns about them. You can specify that your aspect
has no effect at all (therefore you would lie, since it does not make sense to
write an aspect that has no effect) and, therefore, it's like the function
f(x)=x, it
commutes with any other aspect. But then you are supposed to have made an
educated choice (use the custom attribute WaiveAspectEffectAttribute
for this purpose).

Some Theory Behind

The theory behind shows that, while PostSharp Laos became popular quite
accidentally (PostSharp Core was well designed, but PostSharp Laos started as an
experiment), PostSharp 2.0 is really engineered to scale well in complexity and
to assume the burden of this popularity (be certain it is something we carry
both with pleasure and honor).

Before starting to execute transformations on a code element (say a method),
PostSharp gathers all transformations upfront. At this point, they form an
unstructured set of nodes. When this is done, PostSharp evaluates dependencies
between all transformations in the set. Ordering dependencies become edges in a
directed graph/a>
and form a partially
ordered set. Then, it performs a
topological sorting
on the graph to find out in which order transformations should be executed. A
part of this algorithm is to detect cycles, so you will get a build-time error
if two aspects have contradictory ordering requirements. Then, PostSharp checks
if it finds clusters of elements that are not strongly ordered. If it finds
some, it checks that all nodes in the cluster commute with all other nodes.
Finally, it checks if other dependency constraints (conflicts and requirements)
are fulfilled.

This complex algorithm is executed for every method, type, field, property,
or event that is the target of more than one aspect. Fortunately, the number of
aspects on a code element is typically small, so the performance cost is not
daunting in practice. Good news is that it scales in complexity.

Old Good Aspect Priority

"Where is my old AspectPriority property?" It's still there. You can
still specify a priority manually. The priority will be translated into a
dependency and will be merged with dependencies.

While using an aspect, you can always refind the dependencies provided by the
aspect developer. But you cannot break them. If you intend to do so, you will
introduce a circular reference in dependencies:

Conficting aspects on "Dependencies.Entities.Quote/GetQuoteDetailsHtml()
: string": according to aspect dependencies, transformation "Before
Dependencies.Aspects.AuthorizationAttribute (4)" should be located both before
and after transformation "Before Dependencies.Aspects.CacheAttribute (3)".

Thanks to the topological sort algorithm, PostSharp is able to detect longer
dependency cycles and to enforce ordering even in complex situations.

Summary

I have shown how PostSharp 2.0 copes with mutliple aspects when they are
applied to the same code element. One word qualifies the approach: robustness.
Now you can safely use aspects in larger teams and projects. PostSharp is
engineered for.