It’s a pleasure to announce the first preview release of PostSharp 4.2, available for download on our website and on NuGet (make sure to enable pre-releases).

PostSharp 4.2 Preview 1 brings the following improvements:

  • Support for Visual Basic (ready)
  • Runtime performance improvement in ready-made patterns (ready)
  • Threading models improvements (ready)
  • INotifyPropertyChanging and support for Xamarin Forms
  • Code saving metrics

In this post, I will just describe the improvements that are already integrated in PostSharp 4.2 Preview 1.

Visual Basic Support

Initially, PostSharp was equally available to C# and VB because they both compile to MSIL, the level at which PostSharp works. However, with time, we developed language-specific features, and made them available only for C#. Today, thanks to the Roslyn project, we are able to bring these features to VB as well:

  • File/line/column positioning of error messages now works also for VB.
  • PostSharp Tools for Visual Studio now supports VB, but only under Visual Studio 2015.
  • The PostSharp compiler now contains more tests that are specific to VB.

VB is now equally supported as C#. Again, I would like to remind that this is thanks to the Roslyn project, which makes it much easier for everybody to support the VB language. No, VB is not dead, Roslyn gives it a second life.

Amazing performance improvement in ready-made patterns

Amazing means, really, a huge difference. In the case of INotifyPropertyChanged, we are now 10 times faster than PostSharp 4.1. This seems a bit embarrassing and requires a few words of explanation.

As we at PostSharp are writing more and more complex aspects, we have been hitting the performance barrier of the current design of the PostSharp Aspect Framework. This design, dating from 2010, did not envision aspects that would include so many transformations. So, its runtime performance was good (even excellent) for the scenarios it was designed for, but with PostSharp 4.0 we seriously started to reach its limits. The root cause of performance limitations is that the PostSharp currently requires a context object (typically OnMethodBoundaryArgs or LocationInterceptionArgs) to be passed from the target code to the aspect code, and this object is allocated on the heap. This creates significant pressure on garbage collection if the aspect is applied to methods called very often, for instance on property getters. Although this technique is way faster than PostSharp’s competition and by the scenarios targeted by this competition (like logging or transaction handling), this is too slow to serve our new ambitions of bringing a solution to thread safety or INotifyPropertyChanged.

So, we are currently investing in PostSharp Aspect Framework so that aspect code receives its context on the stack (as parameters) and not on the heap. The performance gain is just amazing.

Let me be very clear here: we are not advertising our work on PostSharp Aspect Framework as a feature of PostSharp 4.2. This is a huge work, and we will not finish it in PostSharp 4.2. We only developed and tested the features required by our own ready-made pattern implementations. The “modern” aspect framework will not be documented in PostSharp 4.2, and will justify its own major version, probably PostSharp 5.0. In the meantime, you can try the new undocumented APIes, but at your own risks, and without right to support or bug fixes.

Threading models improvements

In PostSharp 4.2, we would like to finish a few items that did not fit into the 4.0 releases. Threading models were a huge innovation and required a massive amount of work and testing. In the rush to close the 4.0 release (because releasing is a feature, too), we reserved a few work items for later, and now it’s time to go back to them.

The most significant improvement is that we no longer block on async methods. So, if you have an async method in a [Synchronized] or [ReaderWriterSynchronized] class, we will now await for the lock. Previously, we would wait for it synchronously, and you would partially lose the benefit of having an async method. This was a very complex work, relying both on some improvements of PostSharp Aspect Framework that will be made public in PostSharp 5.0, and on awaitable threading primitives. The good thing is that we did the hard work so that you can focus on business code.

Note that there is still a case when we wait synchronously instead of asynchronously, but this is a minor one: after executing a [Yielder] method in a [ReaderWriterSynchronized] class.

The second improvement is that we now have an AdvisableHashSet class in addition to AdvisableCollection, AdvisableKeyedCollection and AdvisableDictionary.

Finally, runtime performance of threading models is now dramatically better as described in the previous section.


Besides support for Visual Basic and code metrics (yet to be released), PostSharp 4.2 is an incremental improvement release. Yet, its runtime performance improvements are so huge that you will want to give it a try.

More at the end of next iteration.

Happy PostSharping!


PostSharp Technologies is pleased to announce the release of PostSharp 4.1, the latest version of the #1 compiler extension for .NET, adding support for design patterns and thread safety to C# and Visual Basic.

PostSharp 4.1 focuses on extending the set of supporting platforms by adding Xamarin (both iOS and Android), Visual Studio 2015, Visual Studio Universal Apps to the list of compatible products, and by improving the level of support of Windows 8 and Windows Phone. PostSharp 4.1 will also support new minor platform updates automatically, without requiring any update of PostSharp itself.

Xamarin Support

This is definitively our biggest headline. PostSharp 4.1 now supports Xamarin at the same level of feature as Windows Phone or Windows Store. Excepted the diagnostics pattern library, all PostSharp features are now strictly cross-platform and have been tested on several physical devices.

PostSharp 4.1 is an excellent choice to build large and complex applications for mobile devices and will deliver the same economies of scale as for desktop or server applications, possible saving thousands of lines of codes and hundreds of defects.

Note that Xamarin Studio is not supported. You must build your application on Windows using Visual Studio in order to use PostSharp with Xamarin.

There’s no specific tutorial on how to use PostSharp with Xamarin. It just works as usually: open your project in Visual Studio, move your caret on a class and add an aspect from the smart tag (in VS 2013) or light bulb (in 2015).

Visual Studio 2015 Support

PostSharp Tools have been fully rewritten to take advantage of the new architecture of Visual Studio 2015.

Improvements include:

  • Light bulbs are used instead of the smart tags: not only it looks better, but it also better integrates with other vendors such as Microsoft, Resharper or CodeRush.
  • Real-time code analysis detects the most common errors in seconds so you don’t even have to recompile.
  • Real-time coding guidance shows you what’s the next step to implement more complex patterns like threading models or undo/redo.
  • More accurate parsing of C# code, resulting in higher reliability of PostSharp editor integration.

PostSharp Tools Improvements

Besides VS 2015 support, PostSharp 4.1 includes other significant improvements in the tooling for Visual Studio:

  • Universal apps, the marketing name for shared projects, are now properly supported.
  • PostSharp Explorer is now much more usable and accurate than before.
  • Conservative NuGet Versioning prevents unwanted updates of your NuGet packages. PostSharp will always try to match the version that you’re already using in your solution and will politely ask if an update is needed.

Other Improvements

  • Windows Phone Get Threading. Additionally to Xamarin, PostSharp Threading Pattern Library now becomes available for Windows and Windows Phone (both Silverlight and WinRT), so you can build apps that are both thread-safe and cross-platform.
  • Code Contracts Localization. You can now customize the text of exception messages. Please see the documentation for details.
  • No Strong-Name Verification at build-time. It does not affect strong names at run-time.
  • Automatic support of minor platform updates. Minor updates (like from 4.5 to 4.5.1) should now be automatically supported without any PostSharp update.


PostSharp 4.1 is all about new platforms. With complete support for Windows Phone, Android and iOS, you can leverage the boilerplate-cutting power of PostSharp to your mobile applications. And we proved we’re ready for Visual Studio 2015, with exciting new features that will improve your productivity.

Happy PostSharping!



It’s hot from the oven! Just this quick post to announce that PostSharp 4.1 RC is out. You can download it from NuGet (make sure to enable pre-releases) or from our web site.

I’ll not completely repeat the previous announcements, but here is a short list of the main features:

    • Xamarin Support, now at the same level of functionality and testing as Windows Phone. It lets you use PostSharp to build applications that target iOS and Android, additionally to Windows, Windows Phone, and Windows 8.
    • Visual Studio 2015 Support, including light bulb integration, live code diagnostics and coding guidance, makes it easier to get started with PostSharp, and then assists you in more complex tasks.
    • Conservative NuGet Versioning prevents unwanted upgrades of PostSharp packages.
    • PostSharp Explorer Improvements let you see where aspects are being used in your code.
    • Shared Projects Support makes PostSharp integration with Visual Studio more relevant in large cross-platform projects.
    • Localizable Code Contracts allow you to customize or localize the runtime exception texts thrown by code contracts.

For more details, please see the previous release announcements.

As usually, RC quality means that we consider the quality of this release to be the same as of an RTM release, with the exception of end-user testing. It also means that the documentation is available.

We won’t have time to blog much more for this RC release, this is why we are hiring a Developer Evangelist to help us do a better job with our communication.

Happy PostSharping!