When we announced PostSharp 3.2 Preview, many of you shared your experience about the new features – especially threading models and undo/redo. We found it was such a significant release it would deserve a major version increase. So today, we’re proud to announce the availability of PostSharp 4.0 RC. There will be no PostSharp 3.2 release. PostSharp 3.2 has just been renumbered 4.0.

You can download PostSharp 4.0 RC from our web site. After you install the Visual Studio Extension, you can update your existing projects using NuGet Package Manager, by enabling the “pre-release” option.

What’s New in PostSharp 4.0?

Write thread-safe code in C# and VB using threading design patterns

Multithreading is difficult because we are reasoning about it at an absurdly low level of abstraction. Functional programming languages attempt to solve this problem by forcing you into a specific threading design pattern: Immutable Object. However, object-oriented programming is the right paradigm for most business applications.

PostSharp 4.0 brings the benefits of threading patterns to C# and VB. Instead of migrating your whole project to a different language, mark individual classes with one of the following custom attributes: [Actor], [Immutable], [Freezable], [Synchronized], [ReaderWriterSynchronized], [ThreadAffine] or (the anti-model) [ThreadUnsafe]. PostSharp will then ensure that your code is correct against the model, and will block you deterministically if this is not the case.

For more information, read Working with Threading Models in our documentation.

Implement Undo/Redo at model level

Undo/redo is one of the most-wanted features, but it is often absent from custom applications because it is so expensive to implement. There is no longer an excuse. The new [Recordable] aspect causes any change to your classes to be recorded, so they can be undone at any time. We provide ready-made buttons for WPF, but you can also build your own easily for Windows Phone or Windows 8.

For more information, read Implementing Undo/Redo in our documentation.

Aggregatable and Disposable Patterns

Aggregation – the parent/child relationship – is a fundamental concept of object-oriented design and a part of the original UML specification. Several design patterns rely on object aggregation. Despite its importance, the idea has not been implemented into programming languages, and is therefore the cause of much boilerplate code in most business applications.

For more information, read Implementing Parent/Child Relationships in our documentation.

Other enhancements in PostSharp Pattern Libraries

NofityPropertyChanged performance

We optimized performance of our famous NotifyPropertyChanged aspect. It is now 4 times faster at runtime.

Improved deadlock detection

The policy now also detects deadlocks involving synchronous calls to the WPF dispatcher.

Enhancements in PostSharp Aspect Framework

Dynamic Advices

In PostSharp 3.1, some advices were purely “static”. Either they were in the aspect, either they were not. In PostSharp 4.0, an aspect can take decisions dynamically about which advices must be added to the target class and members by implementing the IAdviceProvider interface. The interface allows to provide instances of one of the following advices: IntroduceInterface, ImportLocation, ImportMethod, IntroduceMethod.

Aspect Repository

It is now possible for an aspect to know which other aspects have been added to any declaration thanks to the IAspectRepositoryService. Plus, the AspectDiscoveryComplete event allows to run execute logic (typically for validation) after all aspects have been discovered.

Initialization Advices

OnInstanceConstructedAdvice lets you execute code after all constructors of a method have completed. We also added InitializeAspectInstanceAdvice, which extends RuntimeInitializeInstance with a parameter telling for which reason the aspect instance is being initialized.

Faster advice state lookup

Thanks to the DeclarationIdentifier property, it is easier to uniquely identify a member within a type. State can now be stored in an array instead of a dictionary, which makes lookups much faster. We use this feature to persist analysis results at build time and consume them at runtime.

Enhancements in PostSharp Core

Support for C++ assembly references

We solved issues where it was not generally possible to add aspects to a C#/VB assembly that referenced a C++ .NET assembly. The previous workaround (which was to use the managed host) is no longer necessary.

Support for WinRT and Windows Phone 8.1

We completely redesigned our support for .NETCore (the intimate name for .NET on Windows 8 and Windows Phone 8.1), and this is now much more reliable than before.

What did we drop in PostSharp 4.0?

Since we’re following the rules of semantic versioning, a new major release is an opportunity to abandon support for features that caused tension in our design and engineering processes. Therefore, we discontinued the following features:

  • Silverlight,  Windows Phone 7 and Windows Phone 7.5 are no longer supported by the PostSharp Model Pattern Library. The platforms are still supported by the core product itself (PostSharp.dll).
  • The IReaderWriterSynchronized interface has been fully deprecated.

PostSharp 3.1 will remain supported for a while and minor bugs will still be fixed. Issues that require important redesign will no longer be addressed in PostSharp 3.1.

Status of PostSharp 4.0 RC

We take the word release candidate seriously at PostSharp. The RC milestone means that the following criteria were fulfilled:

  • All planned features are implemented.
  • All new APIs have been reviewed and we predict no breaking change will be necessary, even with regard to other envisioned features.
  • All features have been tested internally.
  • A zero-defect point was reached at the time of release.
  • API documentation and tutorials are complete; testers did not report discrepancies or ambiguities in the documentation.

The ball is now in your camp; we need you to try to update your solutions (in a prototype branch) to the new version, run your test suite and report any issue. We will gather feedback during several weeks and promote the release to stable after community testing.


PostSharp 4.0 proposes a realistic approach to thread-safe object-oriented applications. We believe the significance of this innovation exceeds the scope of PostSharp and perhaps even .NET, since the concepts, if proven successful, could be implemented in other programming languages by a new generation of compilers. We’re obviously very proud of this achievement, and can’t wait to get feedback from the field.

Additionally, Windows and Windows Phone developers can now add undo/redo to their application with minimal effort thanks to our new Recordable pattern – a powerful alternative to the Memento pattern.

To realize these two new major features, we had to build new abilities in our aspect framework. You can now rely on these new types of advices to build automation for your own patterns.

We need your feedback to move this release to the stable milestone. Please download it from our web site and let us know what you think.

Happy PostSharping!


Today we’re excited to announce the public availability of PostSharp 3.1 Preview. You can download the new Visual Studio tooling from our website, our update your packages using NuGet Package Manager. In the latter case, make sure to enable the “Include Prereleases” option.

PostSharp 3.1 includes the following features:

  • Support for state machines (async and iterators)
  • Improved build performance
  • Resolution of file and line of error messages
  • Solution-level policies (and a smarter configuration system)
  • Indentation in logging

PostSharp 3.1 is a free upgrade for all customers with a valid support subscription. The license key of PostSharp 3.0 will work.

Support for state machines

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.

PostSharp 3.1 gets much smarter. OnMethodBoundaryAspect now understands that is being applied to a state machine, and works as you would expect. To enable the new behavior, you need to set the OnMethodBoundaryAspect.ApplyToStateMachine property to true. It is false by default for backward compatibility.

But there is more: the aspects define two advises: OnYield and OnResume. For the sake of backward compatibility, we could not add them to the IOnMethodBoundaryAspect interface, so we defined a new interface IOnStateMachineBoundaryAspect with these two methods.

More blogging about this later.

To discover more on your own, try to apply the following aspect to an async method or an iterator:

public class MyAspect : OnMethodBoundaryAspect, IOnStateMachineBoundaryAspect
    public static StringBuilder Trace = new StringBuilder();

    public override void OnEntry(MethodExecutionArgs args)

    public void OnResume(MethodExecutionArgs args)

    public void OnYield(MethodExecutionArgs args)

    public override void OnSuccess(MethodExecutionArgs args)

    public override void OnExit(MethodExecutionArgs args)

Read more about this feature.

Improved build performance

The first time you compile a project using a specific build of PostSharp, you will be proposed to install itself into GAC and create native images.

Doing will decrease build time of a fraction of a second for each project. A potentially substantial gain if you have a lot of projects. You can uninstall these images at any time from PostSharp options in Visual Studio.

Under the cover, PostSharp will just install itself in GAC using gacutil and will generate native images using ngen.  The feature does not affect build servers or cloud builds, so only build time on developers’ workstations will be improved.

Keep in mind that your end-users will not have PostSharp installed in GAC, so you still need to distribute PostSharp.dll.

Resolution of file and line of error messages

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.

I know, it seems like an obvious feature. But it was actually quite complex to implement. PostSharp works as MSIL level and the file that’s supposed to MSIL back to source – the PDB file – won’t tell you where a type, field, or abstract method is implemented. Indeed, it only contains “sequence points”, mapping instructions to lines of code. That is, only the inside of method bodies are mapped to source code.  So, we had to rely on a source code parser to make the missing like ourselves.

This feature is available for the C# language only.

Note that this feature is not yet fully stable. There are still many situations where locations cannot be resolved.

Solution-Level Policies

We made it easier to add a policy to a whole solution. Say you want to add logging to the whole solution. Previously, you had to add the aspect to every project of the solution. Now, you can right-click on the solution and just add it to the solution.

This is not just a UI tweak. To make this scenario possible, we had to do significant work on our configuration subsystem:

  • Support for solution-level configuration files (SolutionName.pssln), additionally to project-level files (ProjectName.psproj).
  • Support for conditional configuration elements.
  • Support for XPath in expressions (instead of only property references as previously).

Thanks to this improvements, you can add not only our own ready-made aspects to the whole solution, but also your own aspects.

The configuration subsystem is currently largely undocumented and there was not a good use case for it until PostSharp 3.0. I’ll blog further about this feature and we’ll update the documentation.

Read more about support for solution-level policies.

Indentation in logging

PostSharp Diagnostics Pattern Library was good at adding a lot of logging, but the log quickly became unreadable because the output was not indented. We fixed that. If the logging back-end supports indentation, we’ll call its Indent or Unindent method. Otherwise, we’ll create indentation using spaces.

Our implementation is thread-safe and still does not require you to add a reference to any PostSharp library at runtime (the reference is required at build time and will be removed).

Improvements in PostSharp 3.0

Note that while working on PostSharp 3.1, we still added some features to PostSharp 3.0. The most important ones are support for Windows 8.1 and Visual Studio 2013. Keeping in pace with changes of development environments is a challenge in itself, and we’re glad this we handled it smoothly, without forcing customers to wait for a new minor version.

Please report any issue on our support forum. We’d love to hear about your feedback.

Happy PostSharping – faster than ever.


We’ve got great news for those of you who have been waiting patiently for a PostSharp online training course to become a reality:

Pluralsight, the online training provider for hardcore developers, announced this week the availability of the PostSharp Fundamentals course authored by senior software developer, trainer, and PostSharp MVP – Donald Belcham.

The course is an introduction to using PostSharp and covers all the fundamentals needed to effectively use it to create basic aspects in your applications. The course includes:

  • Introduction (Why and How to use Aspect-Oriented Programming)
  • Installation (EXE & MSI, NuGet, Source Control, License Management)
  • Out of the Box Aspects (OnMethodBoundaryAspect, OnExceptionAspect, EventInterceptionAspect, etc.)
  • Aspect Lifetime (Compile Time, Serialization & Deserialization, Run Time)
  • Existing Codebases (Approach, Attaching Aspects, Side Effects, Low Hanging Fruit)
  • Deployment (Deployables, Signing Assemblies, Obfuscation)
  • Developer Experience (Debugging, IDE Enhancements)

Many thanks to Aaron Skonnard and his team at Pluralsight for continuing to deliver quality online training from some of today’s leading .NET developers. Also a big congratulations and thanks to our good friend Donald Belcham for his continuing efforts to spread the word about the benefits of using PostSharp for AOP.

Watch Donald’s PostSharp Fundamentals course on Pluralsight >>