VIP Content

In Your User Group

In Your Company

Conferences & UG

Community

Runtime Weaving

Load-Time Static Weaving

This approach is very similar to Compile-Time Weaving, but occurs it occurs at runtime just before the assembly is loaded in memory. This situation is adequate when changing the aspects can require the application to be restarted. In its pure application, it does not enable a true dynamic weaving. PostSharp fully supports this scenario.

A variant of this approach is to add join point to code using static weaving, but add advices to join points at runtime, i.e. without restarting the application. It is not difficult to realize this using PostSharp, but it is not ready as an out-of-the-box feature. The disadvantage of this variant is of course that one should choose a balance between join point density (and so flexibility) and performance. Too many join points will produce a huge and slow code.

Tools:

• PostSharp
• Weave.NET
• Rail

Static Weaving with Dynamic Advices

The code is modified using Compile-Time Weaving techniques (eventually done at load-time, see above) so that 'hooks' are called at some locations. What the hooks really do can be changed at runtime.

Tools:

• Microsoft Enterprise Library (Policy Injection Application Block), augmented by PostSharp4EntLib
• SetPoint

JIT Emission of Classes

This approach works only with public virtual methods and with interfaces. There are two approaches: the first is to generate a proxy class implementing the semantics of an interface. In this case, only interface methods can be aspected. The second approach is to generate a child class inherited from the aspected class; it requires this class to be unsealed and it is limited to virtual methods.

The System.Reflection.Emit namespace can be used. Besides of being limited to interface or virtual methods, this approach only supports the join points located at method boundaries (on entry, on exit, on exception).

Tools:

• Spring Framework for .NET
• Windsor Castle
• Aspect#
• NAspect
• Rapier Loom

Profiler API

The Unmanaged Profiler API of the .NET Framework is initially intended to instrument the code, typically for memory and processor consumption. The same API can be used to execute virtually any code. Since the granularity of the Profiler API is very fine, it is possible to define a large range of join points. The outcome however is that the code has to be executed besides the profiler, which is not aimed to be used in production. This makes this approach inappropriate for commercial software.

Debugger API & Edit and Continue

The idea here is partially similar to the use of the Profiler API, but additionally the edit-and-continue facility can be used to modify MSIL code at runtime. This has the potential to get faster code than with the Profiler API. However, it has the same disadvantages, that is, it is little appropriate for commercial software.

Tools:

• Wicca

Programmatic Tipping

Policy Injection

The term Policy Injection has been introduced recently by the Microsoft Patterns & Practices Team (see the blog of Ed Jeziersky and Tom Hollander) to designate what is fundamentally Aspect-Oriented Programming.

When asked why the name Policy Injection and not AOP, Ed answers:

... the reality is most of our customers have not heard of AOP or AOSD. Please put yourself in their shoes for a second. We wanted a name that was reflective of the use and benefit the block brings, rather than using an unfamiliar term that only the exceptions understand. We also wanted to have no implicit expectations on the design that may be inherited from AO solutions.

So Policy Injection is AOP, or at least a part of it. The reason why Microsoft did not choose the term AOP seems to be that AOP could have been perceived as a boring academic concept, which was fashionable in the .NET community about year 2003.

MSIL Injection

How to inject MSIL instructions?

If you are decided to inject directly MSIL instructions, prepare a stock of aspirins and eventually prepare your girlfriend to being absent from home. Then you may choose between the following approaches.

Language Extension

The most popular approach so far has been to define extensions to the base language, i.e. a new language based on the language of the aspected code. The de-facto standard in the Java culture is AspectJ. The following example is taken from the AspectJ Programming Guide:

 1 aspect FaultHandler {
 2
 3   private boolean Server.disabled = false;
 4
 5   private void reportFault() {
 6     System.out.println("Failure! Please fix it.");
 7   }
 8
 9   public static void fixServer(Server s) {
10     s.disabled = false;
11   }
12
13   pointcut services(Server s): target(s) && call(public * *(..));
14
15   before(Server s): services(s) {
16     if (s.disabled) throw new DisabledException();
17   }
18
19   after(Server s) throwing (FaultException e): services(s) {
20     s.disabled = true;
21     reportFault();
22   }
23 }

As you can see, lines 3-11 is pure Java but 13-22 use the AspectJ extension. Even if the purpose of this section is not to explain the AspectJ syntax, note the pointcut, before and after keywords.

The advantage of this approach is that the semantics of the language adapted on purpose, so the resulting code is clean and consistent. No 'trick'. A drawback is that this approach is language-dependent, if your aim is to develop a weaver, you have to develop a code enhancer for every targeted language. See the Compile-Time Weaving techniques for details. A weaver developer should also ideally provide integration with the IDE (Intellisense).

It is not possible to write an aspect weaver of this type using PostSharp, because PostSharp supposes that the code has already been compiled. Also, Runtime Weaving techniques are all unadapted for this scenario.