Today we’re excited to announce the release of PostSharp 4.1 Preview 4, available for download on our website and as pre-release packages on our NuGet feeds. We silently released two other previews since our last announcement. PostSharp 4.1 is all about supporting new platforms and it is now feature-complete. Let’s see what’s new in the box:

  • Support for Xamarin
  • Windows Phone and Windows
  • Visual Studio 2015
  • Conservative NuGet Versioning
  • Localizable Code Contracts
  • PostSharp Explorer Improvements


It made the top of our UserVoice wish list for a long time: Xamarin is now supported as a first-class member of the .NET family. All features of PostSharp, including thread safety patterns, INotifyPropertyChanged and undo/redo, are now available for Xamarin through portable class libraries (PCL).

How to use PostSharp with a Xamarin project? Just as it works with other projects. Use the smart tag or the light bulb to add a PostSharp aspect, or install the PostSharp NuGet package. It’s that simple.

More about Xamarin integration in a later post.

Windows Phone and Windows Store

You could already create your own PostSharp aspects or use the built-in INotifyPropertyChanged and undo/redo aspects with Windows Phone and WinRT. With PostSharp 4.1, you can now use PostSharp Threading Pattern Library to create truly cross-platform thread-safe apps. Additionally to .NET Framework and Xamarin, we also ported and tested thread safety library with Windows Phone and Windows Store.

Visual Studio 2015

We’ve continued to work on support for Visual Studio 2015, and PostSharp is now compatible with VS 2015 CTP 5. There are two different scenarios to be considered:

  • C# and VB compilers. As you know, Visual Studio 2015 ships with a completely new generation of compilers. They break some assumptions that previous versions of PostSharp were doing. Therefore, if you build working code with VS 2015, you may cause previous versions of PostSharp to crash or invalid code to be generated. We want you to know that we take this situation extremely seriously and that we are committed to provide support for the new compilers in PostSharp 3.1, 4.0 and 4.1. Therefore, you are not forced to upgrade to new major version of PostSharp. However, you must upgrade to the newest build of your current PostSharp minor release if you want to upgrade to Visual Studio 2015.
  • Visual Studio Editor. We made a significant investment to ensure the optimal user experience of PostSharp in Visual Studio 2015. Not only did we replace the smart tag with the modern light bulb, but we also added live code diagnostics and assistance.

More about Visual Studio integration in a later post.

Conservative NuGet Versioning

In the past, adding a new aspect using the smart tag or light bulb could cause the PostSharp packages to be silently upgraded to the latest version. This is how the NuGet client works by default, but this is quite annoying. PostSharp 4.1 will now always try to respect the version of PostSharp that you are already using in the solution. If a package upgrade is required because the version you are using does not support the requested feature, PostSharp will request your consent before upgrading the package.

Localizable Code Contracts

It is now possible to customize the exception messages generated by PostSharp Code Contracts, and therefore localize them. The API is based on a chain of responsibility, into which you can insert your own message provider. The implementation does not rely on managed resources so it is easier to customize. The feature is not yet documented. Start from class ContractLocalizedTextProvider for more information.


With this new release, PostSharp becomes really cross-platform. Whether you are developing desktop applications with WPF or mobile applications for Windows Phone, Windows 8, Android or iOS, you can rely on PostSharp to deliver features quicker with source code that is more concise, cleaner and more reliable.

PostSharp 4.1 is now feature-complete and there are now just a few issues (documented in the release notes) that we need to solve before we can call it a release candidate. It’s a great time to try PostSharp 4.1 if you are not on a tight go-to-production schedule.

We’re really eager for feedback from Xamarin and mobile developers, so don’t hesitate to contact us with any question, remark or frustration.

Happy PostSharping!


Just one month after we published PostSharp 4.0 RTM and one week after Visual Studio 2015 Preview went out, we’re excited to release PostSharp 4.1 Preview 1 today, introducing support for Xamarin and Visual Studio 2015. PostSharp 4.1 is all about adding support for new platforms. We want to make PostSharp the number-one extension for pattern-driven programming – not only for desktop and server applications, but also for mobile devices.

PostSharp 4.1 Preview 1 is available for download from our web site and from NuGet as a pre-release package. Note that this is still an early preview, and needless to say PostSharp Tools for Visual Studio 2015 are particularly experimental.

Support for Xamarin

A few years ago, PostSharp had an ambiguous relationship with Mono. Technically, it was possible to run PostSharp on Mono, and there were even a few classes written specifically for this use case. However, we didn’t have any significant testing with Mono. So  even if we said we “supported” it, the idea was really just: use PostSharp with Mono at your own risks.

Starting with PostSharp 3, we decided to take the term support more seriously. If we said PostSharp would support a platform, it means that we had automated tests for it, that we would have a development and testing lab, and that we would answer support requests. To support a platform is much more than merely hoping for eventual compatibility. So, we decided to remove Mono support in PostSharp 3. This was not a bad decision; we could not afford another anyway.

But since last week, things are different. Microsoft announced an enhanced partnership with Xamarin to make .NET the most productive development platform for all devices, from wearable to cloud . Through its potential to reduce the size and complexity of .NET code by 20%, PostSharp is a natural fit in this effort to increase developer productivity. Today, we’re announcing that PostSharp 4.1 embraces the cross-platform vision.

Limitations in PostSharp 4.1 Preview 1

This early release is an important milestone but there’s still much work to do:

  • We only added support for Xamarin into the PostSharp package, but not to the pattern libraries. That is, you can create your own aspects for Xamarin, but you cannot use the pre-built ones yet. Pattern libraries will be ported in a later release.
  • We only support a few Xamarin profiles. More will be supported later.
  • You can build only from Visual Studio. The Mac compilation server is supported but your main build machine must be Windows. Mac as a main developer workstation will not be supported in PostSharp 4.1.

Support for Visual Studio 2015

From our point of view, Visual Studio 2015 is the most significant release since Visual Studio 2005, when PostSharp started to integrate with the IDE. We had to rewrite significant portions of our software to take advantage of the new version. The new code is not only simpler, it is also faster and allows for more features and better integration.

When using PostSharp 4.1 with Visual Studio 2015, you will see the following differences:

  • Integrate with the light bulb instead of the smart tag. It’s a small difference but it will provide a more consistent experience. Smart tags didn’t scale well with multiple vendors (Microsoft, PostSharp and CodeRush for instance), but the light bulb has been designed for this.
  • Real-time detection of some errors. For instance, when making a class recordable or thread-safe, you know in real time that a field must be annotated with [Child] or [Reference].
  • Advanced code fixes. When making a class recordable or thread-safe, collection child fields have to be changed from List to AdvisableCollection. There’s now a code fix to do this change automatically, and it even updates field assignments where possible.

What’s Next in PostSharp 4.1?

In the next weeks, we’ll be working on the following improvements:

  • PostSharp Threading Pattern Library: support for Windows Phone, Windows Store and Xamarin.
  • PostSharp Model Pattern Library: support for Xamarin (Windows Phone and Windows Store are already implemented in 4.0).
  • Xamarin: support for all profiles.
  • Visual Studio 2015: tuning of the user experience.

You should now see a new release every 3rd week.

Happy PostSharping!


Today we’re excited to announce the general availability of PostSharp 4, the newest version of our 100%-compatible productivity extension to C# and VB. PostSharp allows developers and architects to automate the implementation of design patterns by encapsulating them into reusable components named aspects. Unlike other development productivity tools, PostSharp does not just make it easier to type code, but results in a smaller codebase that is easier to understand and has fewer defects.

You can download PostSharp 4 today from Visual Studio Gallery and update your projects using NuGet.

PostSharp 4 applies the success of pattern-driven development to the realm of multithreaded applications and provides a thread-safe extension to C# and VB. Application developers can annotate their classes with custom attributes such as [Immutable], [Actor] or [Synchronized] and have their code automatically validated against the model. Any violations result in build-time errors or run-time exceptions instead of data corruptions.

PostSharp 4 makes it incredibly easy to implement undo/redo in desktop and mobile applications by automatically recording changes in model objects. Additionally, it includes more than 15 other improvements and enhancements.

Information in this release announcement includes:

Threading Models

When comparing modern object-oriented programming to assembly language, one can see that notions like classes, fields, variables or methods really simplify developers’ lives and increase their productivity. But when it comes to multithreading, one cannot state that object oriented programming (OOP) delivers so much value. As a result, multithreading is still being addressed at a low level of abstraction with locks, events or interlocked accesses. The resulting cost for the industry, in terms of development effort and number of defects, is enormous.

Alternatives to OOP like functional programming and actor programming have been proposed to address the challenges of multithreading. However, these paradigms are not as appropriate as OOP for business and mobile applications. They have failed to gain wide adoption, existing only in narrow niches where high performance wins over high development cost.

Instead of trying to replace OOP, PostSharp 4 extends the C# and VB languages with custom attributes like [Immutable], [ThreadAffine], [Synchronized] or [Actor], which allow developers to assign a threading model to a class. Based on these custom attributes, the compiler extension validates the code against the model and generates synchronization or dispatching instructions.

PostSharp 4 implements the following threading models:

  • Immutable and Freezable;
  • Synchronized and Reader-Writer Synchronized;
  • Actor;
  • Thread Affine and Thread Unsafe.

What are the benefits?

Thanks to threading models, source code is safer and simpler. Threading models bring the same kind of productivity gains than the stricter C#/VB memory model brought to C++. Source code is more concise and easier to reason about and there are far fewer chances for non-deterministic data races. Threading models make it easier for everyone on the team, not just for multithreading experts, to build robust business applications.

Why is this a significant innovation?

We believe that our approach to multithreading is innovative in many ways, and that its significance exceeds the scope of the PostSharp community. Points of interest include the focus on business applications and average developers (instead of critical software and expert developers); the idea that several threading models can co-exist in the same application as an extension of a mainstream language (instead of requiring a rewrite in a specialized language); and the use of UML aggregation as a foundation to select the synchronization granularity.

See our technical white paper for more details about our approach. We think this new approach could be applied to other object-oriented languages and environments.

Additional Resources

For more information, see:


A feature that always scores at the top of each the wish list of each application is undo/redo. Oddly enough, the feature usually remains unaddressed for years because it is awfully painful to implement using conventional technologies. It simply generates too much boilerplate code.

PostSharp 4 takes the boilerplate code out of way. Just add the [Recordable] attribute to your model classes, and they will start appending any change into a Recorder. You can then use the Undo and Redo methods of the Recorder, or add the off-the-shelf WPF buttons to your toolbar.

What are the benefits?

PostSharp 4 makes undo/redo affordable for virtually any application, even line-of-business software that typically has a large object model and a small user base. Previously, the feature had a prohibitive cost and would pay off only in simple applications or software with a large customer base.

The Recordable pattern offers more flexibility than the traditional Memento pattern, and its implementation can be completely automated by the compiler. It demonstrates how better compiler technologies can lead to simpler source code and reduced development effort.

Additional Resources

For more information, see:

Aggregation and Composition

When we built our threading models and undo/redo feature, we realized that we needed a notion of parent-child relationships. When we kept thinking deeper about that, it became clear that most object designs actually relied on this notion. It’s not surprising if one considers that aggregation and composition are core concepts of the UML specification. Yet, it’s a pity it has not been implemented in programming languages. We needed to fix that.

Classes that can be involved in parent-child relationships must be annotated with the [Aggregatable] custom attribute, or with any other attribute that implicitly provides the Aggregatable aspect. Then fields that hold a reference to another object must be annotated with [Child], [Reference] or [Parent].

The principal role of the Aggregatable aspect is simply to automatically set the parent property when a child is assigned to a parent and to implement a child visitor.

For more information, see:

Other Improvements

In addition to the previously described new features, we significantly enhanced the PostSharp Aspect Framework and worked on other components as well:

More Free Aspects in PostSharp Express

PostSharp 4 generalizes the idea of giving our ready-made pattern libraries for free for small projects. PostSharp Express 4 now includes the following features for free – for up to 10 classes per Visual Studio project:

  • NotifyPropertyChanged
  • Recordable, EditableObject (undo/redo)
  • Aggregatable, Disposable
  • Threading (threading models, dispatching)
  • Code Contracts
  • Logging (up to 50 methods)

If you like the new features and want to use them more, you can buy them as a part of PostSharp Ultimate or as an individual product. More on our pricing page.

Platforms Newly Supported

PostSharp 4 adds full support for:

  • Win RT both on Windows 8 (the previous support was error-prone and needed a complete redesign) and Windows Phone 8.1.
  • Windows Phone 8.1 “Silverlight”.
  • C++ “mixed mode” assembly references.

Platforms No Longer Supported

We decided that new releases of PostSharp would not support platforms for which Microsoft no longer provides mainstream support at the time of a PostSharp RTM release.

On development workstations and build machines, PostSharp 4 no longer supports:

  • Windows XP (Vista, 7 or 8 is required).
  • Visual Studio 2010 (2012 or 2013 is required).
  • .NET Framework 4.0 (4.5 is required).

On end-user devices, PostSharp 4 no longer supports:

  • .NET Framework 2.0 (3.5, 4.0 or 4.5 is required).
  • Windows Phone 7 (8 or 8.1 is required).
  • Silverlight 4 (5 is required).

Note that PostSharp 3.1 still supports these platforms.


While Microsoft has lately been catching up with its competitors in the consumer market, enterprise developers may feel neglected. At PostSharp, our focus is to increase productivity of large .NET development teams. It’s only when you start counting lines of code with 6 or 7 digits – and you realize that every line may cost your employer between $10 and $20 – that you appreciate and receive the full benefits of automating design patterns.

PostSharp 4 marks a significant innovation in the realm of multithreading. It raises the level of abstraction by defining models so the machine can do more and humans must think less. But instead of requiring developers to switch to a different language, it respects their investments in C# and VB and extends the environment in a backward compatible fashion.

PostSharp 4 includes plenty of important new features including undo/redo, parent-child relationships, performance improvements, new advices and more.

It’s an exciting time to be a developer.

Happy PostSharping!