NOTE: This blog post is about an available pre-release of PostSharp. You can install PostSharp 4.0 only using NuGet by enabling the “Include pre-release” option.

At PostSharp Technologies, we see our role as making it easier to build good software. We believe that source code, and not UML diagrams or documentation, should be the reference artifact. If the goal is to make it easier to build good software, then we should necessarily focus on making source code simpler. Ideally, the source code should be at the same level of abstraction as our thinking. So if we are thinking in terms of design patterns, we should be able to code in terms of design patterns. Unfortunately, conventional compilers have no concept of design patterns. This is why we built PostSharp: to empower developers to tell their compiler what needs to be done, not how to do it.

In PostSharp 4.0, we decided to implement more design patterns and to do it better. After some reflection, it became clear that many design patterns rely on a fundamental concept: the parent-child relationship. This is so common that we easily forget about it. Yet how many times did you find yourself implementing a parent-child relationship manually?

To move forward with other design patterns, we had to provide a good implementation of the parent-child relationship. We decided to stick to the UML terminology, where this kind of relationship is named an Aggregation. Objects in an aggregation relationship form a tree (acyclic graph). UML also defines a kind of relationship named a Composition. A composition relationship is a parent-child (or whole-part) relationship where the lifetime of the children is controlled by the parent; when the parent is destroyed, all children must be destroyed in cascade. Aggregation and composition are often considered equivalent in garbage-collected platforms because there is no explicit lifetime control. In .NET, the Composition pattern makes sense in combination with the Disposable pattern, i.e. children are disposed when the parent is disposed.

How did we do it in PostSharp 4.0?

Aggregatable Aspect

The core of our implementation of the Aggregation pattern is the Aggregatable aspect. Any class whose instances may need to be a part of an aggregation must be annotated with the [Aggregatable] custom attribute. You will find this aspect in the PostSharp.Patterns.Common library and the NuGet package.

Let’s examine this aspect in action on a simple example where an invoice entity is composed of one instance of the Invoice class and several instances of the InvoiceLine class:

public class Invoice
    public readonly AdvisableCollection<InvoiceLine> Lines = new AdvisableCollection<InvoiceLine>();

    public readonly AdvisableCollection<InvoiceDiscount> Discounts = new AdvisableCollection<InvoiceDiscount>();

    public Customer Customer;

public class InvoiceLine
    public Product Product;

    public Invoice ParentInvoice { get; private set; }

public class InvoiceDiscount
    public decimal Percent;
    public string Reason;

    public Invoice ParentInvoice { get; private set; }

As shown, fields and automatic properties are annotated with the following custom attributes:

  • [Child] means that the field/property value is a child of the current instance.
  • [Parent] means that the field/property must be automatically set to the parent whenever the current instance is assigned to a [Child] field/property of another object.
  • [Reference] means that the value is neither a [Child] neither a [Parent].

Value-type or primitive-type fields and properties don’t need to be annotated. Note that it is allowed to assign a non-aggregatable object to a child field; the child object will be visible to the parent anyway.

IAggregatable interface

At this point, you may wonder 1) why we need an aspect to maintain the child-parent relationship, and 2) what is the aspect’s benefit over plain C# code.

The real motivation of the Aggregatable aspect is to expose the parent-child relationship as an abstraction that can be consumed by other components that don’t have knowledge of the shape of the domain objects.

The aspect makes this possible by automatically implementing the IAggregatable interface as below:

public interface IAggregatable 
    bool VisitChildren(ChildVisitor visitor, ChildVisitorOptions options);
    object Parent { get; }
    Relationship ParentRelationship { get; }
    event EventHandler ParentChanged;
    event EventHandler AncestorChanged;

    // Implementation details omitted.

The VisitChildren method allows any consumer to execute a delegate for each child of the object without knowing where these children are stored. In our Invoice example, children are stored both in the Lines and Discounts collection. It may seem weird to present children using a visitor rather than an enumerable, and we chose this design intentionally for performance reasons because the pattern can then be implemented without resorting to additional data structures.

AdvisableCollection and AdvisableDictionary

In the above example, you can see that the type of the Lines and Discounts fields of the Invoice class is special: AdvisableCollection. We clearly needed a special collection that would implement the Aggregatable pattern: minimally, we need a collection to set the Parent field of all children objects.

We could create an AggregatableCollection for the Aggegatable pattern, then a FreezableCollection for the Freezable pattern, then a ReaderWriterSynchronizedCollection, and so on. Every time you want to add a behavior to an object model, there is a need for a specialized collection type. This situation would quickly become unmanageable.

Instead, we decided to create a general collection to which behaviors can be added dynamically at runtime. An AdvisableCollection or an AdvisableCollection automatically implements the Aggregatable pattern as soon as it is assigned to a [Child] field of an Aggregatable object. This may sound a bit strange but this is plain old object-oriented programming, and no MSIL transformation is involved in this feature.

Since part of the Aggregatable pattern is to implement the IAggregatable interface, we needed a way to dynamically add interfaces to an object. This is clearly impossible in .NET, so instead we chose not to reinvent the wheel and borrow from COM’s QueryInterface method.

So, when you need to cast an AdvisableCollection to IAggregatable, you can use:

IAggregatable aggregatable = collection.QueryInterface<IAggregatable>();

Disposable Aspect

A composition relationship is, by definition, an aggregation relationship where the parent controls the lifetime of children. In .NET terms, it means that the Dispose method of a parent should invoke the Dispose method of children.

This is exactly what we did with the Disposable aspect. Based on the Aggregatable pattern, the Disposable pattern automatically implements the IDisposable interface, calling the Dispose method of all children in a depth-first traversal.

The Disposable aspect automatically adds the Aggregatable aspect if it is not yet applied to the type. Note that the leaves of the object tree don’t need to have the Disposable aspect if they already implement the IDisposable interface.

The following example demonstrates a composition of three classes: Multiplexer, Sink and TextWriter.

class Multiplexer
    AdvisableCollection<Sink> sinks = new AdvisableCollection<Sink>();

    public void WriteLine(string text)
        foreach (Sink sink in sinks)

class Sink
    private TextWriter textWriter;
    public Sink(TextWriter textWriter)
        this.textWriter = textWriter;

    public void WriteLine(string text)

In the example above, all TextWriter instances will be disposed when the parent Multiplexer instance will be disposed.


PostSharp 4.0 now provides a ready-made implementation of two fundamental object relationship patterns: Aggregation and Composition. This lays the ground for other pattern implementations such as freezable, immutable, recordable and synchronized. The curious reader will find some of these patterns.
We’ll blog about these other patterns in the next days.

UPDATE: Change product version from PostSharp 3.2 to PostSharp 4.0.

As I look back at 2013, I am reminded of how much pain it sometimes takes to make a difference in the world, but how immense is the reward when what you believe in slowly comes true.

A year ago we were already 6 months late on the Microsoft release cycle. This year we added support for Visual Studio 2013 and .NET 4.5.1 the next day after the preview release and we soon caught up with the C# compiler.

A year ago, I almost lost faith in aspect-oriented programming. Today I strongly believe in a better, fundamentally simpler way to think about software. I believe a once-in-a-generation paradigm shift is coming. It will be an era in which developers will tell compilers what to do and not how to do it. In this vision, aspect-oriented programming plays a central goal in concert with static analysis and meta-programming. Today, we are proud as we contribute to the evolution of programming languages.

A year ago the company was in crisis. Today the team is solid and confident. This is why now my looking back is filled with gratitude and thanks for many.

I give thanks to our customers, those small teams of engineers who fight hard within their corporate bureaucracies to be allowed to use non-mainstream technologies.

I give thanks to our local team, who chose the shivers on the Santa Maria across unknown waters over the safety of cabotage in familiar territory.

I give special thanks to Marek Byszewski’s team for its crucial support during the storm, and to Art of Change’s Vlasta and Jana for their help in strengthening the team and our minds.

Last but not least, I give thanks to the Friends of PostSharp, those benevolent speakers who dedicated their free time to educate the community. Together, the Friends of PostSharp reached an audience of over 1,000 just this year.

We were looking for a way to express our gratitude and we thought there would be no better way than a donation to a charity on behalf of our community. We wanted to support a worthwhile cause that resonates with our industry. Thankfully, we were able to find a great one.

In the name of the Friends of PostSharp, we have donated $2,000 to the Czech Association Helping People with Autism (APLA).

Autism diagnoses have surged in the last few years and associations like APLA struggle to meet the demands of parents. Causes of the disease are still being debated. But beyond the usual jokes about socially-odd programmers, researchers have found signs that autism may indeed be more prevalent among children of those in highly intellectual and technical professions. Autism is a focal concern of industrialized societies and especially of high-tech professions.

Last for Matt, Donald, Dustin, Lance, Dror, Adam, Yan, Joe and Chad, thank you so much for your dedication and support.

We wish you all at least a few work-free days without PostSharp before the 2014 New Year.

Happy Christmas from all of us at PostSharp Technologies!


We’re excited to announce that PostSharp 3.1 RTM is now available for download from Visual Studio Gallery and NuGet.

Before we even mention the new features, we have good news for those who are just interested in a specific functionality in PostSharp such as logging or INotifyPropertyChanged:

PostSharp Pattern Libraries Available as Stand-Alone Purchases

It is now possible to purchase PostSharp Pattern Libraries separately so you don’t have to buy PostSharp Ultimate if you only need a small part of it. Please check the prices online and let us know if you have any questions.

What’s New in PostSharp 3.1

PostSharp 3.1 builds on the vision of PostSharp 3.0, but makes it more convenient to use. It also catches up with the C# compiler features, and adds more flexible licensing options. You can read more about the new features in the PostSharp 3.1 Preview Announcement. In short, PostSharp 3.1 brings you:

  • faster builds: PostSharp can now optionally install itself in GAC and generate native images. This decreases build time of a fraction of a second for each project: a substantial gain if you have a lot of projects.
  • support for async and iterator methods: when you applied an OnMethodBoundaryAspect to a method that was compiled into a state machine, whether an iterator or an async method, the code generated by PostSharp would not be very useful:  the aspect would just be applied to the method that implements the state machine. An OnException advise had no chance to get ever fired. Starting from PostSharp 3.1, OnMethodBoundaryAspect understands that is being applied to a state machine, and works as you would expect.
  • solution-level policies and improved configuration system: PostSharp 3.1 makes it easier to share configuration across several projects. For instance, you can now add aspects to all projects of a solution in just a few clicks.
  • locations (file/line) of errors and warnings: when previous versions of PostSharp had to report an error or a warning, it would include the name of the type and/or method causing the message, but was unable to determine the file and line number. You can now double-click on an error message in Visual Studio and you’ll get to the relevant location for the error message.
  • automatic indentation in logging: for better log readability, PostSharp Diagnostics Pattern Library now automatically indents log entries when entering and exiting methods.

All customers with an active maintenance subscription can upgrade to PostSharp 3.1 for free.

Happy PostSharping!