This is the online documentation for PostSharp 5.0.
Download PDF or CHM. Go to v4.3 or v5.0

Key Technologies

PostSharp combines several technologies to leverage design pattern automation:

Metaprogramming

Metaprogramming is the writing of a program that analyzes and transforms itself or other programs. PostSharp internally represents a .NET program as a mutable .NET object model, so PostSharp can be considered a metaprogramming tool for .NET.

However, general metaprogramming (the ability to perform arbitrary modifications on a program) is a highly complex discipline. Although it may seem easy to perform simple modifications on simple programs, it is actually much more difficult to implement non-trivial transformations that work in all cases. Metaprogramming can result in a decrease in productivity when used improperly and it is very difficult, for application developers who lack specific training in compilers and metaprogramming, to use it properly.

Since general metaprogramming is too complex and too low level, we need a higher layer of abstraction that makes it easier and safer to express program transformations. Essential qualities of this abstraction layer would include safe composition of several transformations on the same declaration and restrictions on changing the program semantics.

Aspect-Oriented Programming fulfills these qualities as a disciplined approach to metaprogramming.

Aspect-Oriented Programming

PostSharp Aspect Framework is built on the principle of Aspect-Oriented Programming (AOP), a well-established programming paradigm, orthogonal to (and non-competing with) object-oriented programming or functional programming, that allows to modularize the implementation of some features that would otherwise crosscut a large number of classes and methods.

We can confidently say that PostSharp is the most advanced AOP framework for Microsoft .NET.

For details on PostSharp's implementation of AOP, see Developing Custom Aspects.

Static Program Analysis

Static program analysis is the analysis of a program without executing it.

There are two families of static analysis tools:

  • Structural static analysis tools analyze the program's declarations and instructions, but do not attempt to understand the run-time behavior of the program. Microsoft Code Analysis belongs to this category.

  • Behavioral static analysis tools are based on iterative techniques like abstract interpretation, model checking or data-flow analysis. Behavioral static analysis is much more complex and time consuming. Microsoft Code Contracts belong to this category.

PostSharp contains tools for structural static analysis only. These tools consist in complete access to the System.Reflection model of the assembly being built, navigating through code relationships using the ReflectionSearch facility, and an expression tree decompiler.

The most important use case for static analysis in PostSharp is when writing aspects, in order to determine how the target program should be transformed. Any of the static analysis tools can be used to build aspects. This contrasts with other AOP implementation like AspectJ, which defines its own specific language (pointcut language) to select target declarations.

Aspects like NotifyPropertyChangedAttribute or threading models make advanced use of static analysis.

A secondary role for static analysis is architecture validation. This role is marketed as the PostSharp Architecture Framework, which defines a notion of architectural constraint. see Validating Architecture for more information.

Dynamic Program Analysis

Dynamic program analysis is the analysis of a program during its execution. Dynamic analysis is often used to detect issues early, before they cause bigger damage. A typical example of dynamic analysis is the one that occurs when an object is cast to a type: when the safety of the type conversion cannot be proved using static analysis, the type conversion must be verified at run time, and an InvalidCastException is thrown when an invalid cast is detected.

PostSharp uses dynamic analysis to check the program against threading models. Since many model properties cannot be reliably verified at build time, they must be enforced at run time. For instance, with the Synchronized threading model, accessing a field without owning access to the object would result in a ThreadAccessException. For details, see Writing Thread-Safe Code with Threading Models.

Another example of use of dynamic program analysis in PostSharp is deadlock detection. For details, see Detecting Deadlocks at Runtime.

In PostSharp, dynamic analysis is achieved by adding instrumentation aspects to the program.