Today we’re excited to announce the release of PostSharp 4.2, available for download on NuGet and Visual Studio Gallery .

This release comes more than 10 months after PostSharp 4.1, and during most of this time the team was focused on a single objective: to improve the quality, performance and usability of existing features. The result: thread-safe design patterns, NotifyPropertyChanged and VB support are now way better than before. PostSharp 4.2 also includes brand new features like code metrics and experimental support for ASP.NET v5.

Threading Models Made Usable

When we announced PostSharp 4.0 in October 2014, we were truly excited to bring a huge innovation to the .NET community and even to the OOP world. This innovation was the ability to write thread-safe code in a mainstream object-oriented language thanks to compiler-supported design patterns. It was not the first time that design patterns were used to achieve thread safety, but this time design patterns were not mere implementation guidelines that developers would benevolently follow: thanks to PostSharp 4.0, patterns are enforced and implemented by the compiler based on declarative indications given by the developer as custom attributes. PostSharp 4.0 gave design patterns a new dimension: the ability to be automatically implemented or verified by the machine, not only saving costly development time, but also avoiding defects.

Proud of our 4.0 release, we decided to dogfood it in a real-world project of us: our PostSharp Tools for Visual Studio, a medium-sized but fairly complex multithreaded codebase. Well, to be perfectly honest, we learned a lot during this project, and found so many issues that we decided that next time we would dogfood before our RTM release.

Today we’re proud to announce that our thread-safety design patterns have reached a new level of quality and usability, with the following improvements:

  • Huge run-time performance improvement. Much lower load on GC at runtime.

  • New ThreadSafetyPolicy attribute to emit warning when a class is not assigned to any threading model or when a static field is not of a thread-safe type. See Making a Whole Project or Solution Thread Safe for details.

  • Better support for async methods: for lock-based models, locks are being awaited asynchronously instead of synchronously.

  • In the actor model, methods with non-void return type are now allowed and their execution will be done in the actor context, but the calling thread will wait synchronously for the execution to complete. Void but non-async methods must now be annotated with [Dispatched] (until the next major version) to specify if execution must be synchronous or asynchronous.

  • New advisable class AdvisableHashSet<T> as a replacement for HashSet<T>.

  • New methods to the AdvisableCollection<T> class: AddRange(IEnumerable<T>) , InsertRange(Int32, IEnumerable<T>) , RemoveRange(Int32, Int32).

  • Support for immutable collections like ImmutableArray or ImmutableDictionary.

  • Support for type adapters to allow third-party classes (at least read-only ones) to work with the Aggregatable pattern. See TypeAdapter for details.

  • Ability to programmatically and automatically mark a field as child or reference without having to use a custom attribute in source code. See FieldRule for details.

Note that these improvements also apply to other consumers of the Aggregatable pattern, principally the undo/redo feature.

Visual Basic Supported, Now Seriously

Since PostSharp operates on MSIL code, VB has been supported from the first day. However, we had no specific test coverage for VB, some VB-specific language constructs were badly supported. Additionally, several features were not available in VB, including PostSharp Tools for Visual Studio and resolution of file/line location in error messages. We decided these were too many gaps and that we had to make a choice: either drop advertisement for VB support or do it properly. We chose the latter.

Starting with PostSharp 4.2, Visual Basic is fully supported at the same level as C#. And, yes, we now have tests written in VB.

Note that VB support in Visual Studio is available for VS 2015 only because it relies on the Roslyn infrastructure. There are periodically speculations in the community that “VB is dead”, but Roslyn gives it a second life. PostSharp 4.2 is the proof.

NotifyPropertyChanged Improvements

PostSharp 4.2 keeps up with C# 6.0 and specifically with the long-awaited, Elvis-nicknamed “?.” operator.

Previously, PostSharp’s implementation of INotifyPropertyChanged was already able to cope with property chains like "this.model.Address.City” . It now also supports chains that use the “?.” operator instead of “.”, for instance "this.model?.Address?.City”.

As a bonus, we now also support properties that depend on properties of variables that are set in conditional blocks (because this is what the Elvis operator does under the hood). For more information regarding this feature, see the PostSharp 4.2 RC announcement .

That’s not all. We also support INotifyPropertyChanging.

Oh, and we also did amazing performance improvements in this release. I mean terrific: we’re now 10x faster at runtime than with PostSharp 4.1.

Aspect Framework Improvements

Although the aspect framework was not our main focus in this release, we added the following features to support the previous improvements:

Code Saving Metrics

First we believed it would be a non-feature for developers and we did it for, hum, sales and marketing purposes. But the feedback we got is overwhelmingly positive.

Briefly said, PostSharp Tools for Visual Studio now tell you how many lines of hand-written code you have, and many lines of code you saved thanks to PostSharp. To see the metrics, build your project and go to the PostSharp / PostSharp Metrics menu item.

You can customize the amount of code considered save whenever one of your custom aspects is applied to a target declaration. For details, see Estimating Code Savings .

Experimental Support for ASP.NET v5

Even if ASP.NET v5 is still preview, we are already providing some experimental support for it. Given the high fragility of ASP.NET v5 public APIs, we are shipping the ASP.NET v5 connector in a separate open-source project named PostSharp.Dnx, hosted on GitHub. Please look at the project home page for instructions.

This experimental connector only supports the .NET Framework, i.e. neither CoreCLR nor Mono is supported.

Note that our plan is to merge PostSharp.Dnx into our main PostSharp package when ASP.NET v5 and the PostSharp connector will be more stable.

To make it possible to open-source the DNX connector, we had to publish a new NuGet package named PostSharp.Compiler.Client , which defines an API to invoke PostSharp. The MSBuild connector now also uses PostSharp.Compiler.Client.

Summary

PostSharp 4.2 significantly improves the performance and usability of the features introduced in PostSharp 4.0, namely the threading, aggregatable and undo/redo design patterns. It also brings first-class support for VB and makes our NotifyPropertyChanged aspect understand the new Elvis (?.) operator of C# 6.0.

At PostSharp, we’re more than ever focused on making .NET development more productive, more enjoyable and more reliable. The way we’re achieving this is to put the compiler at work and make it write the boilerplate code for you. To give you an idea of how many lines of boilerplate code you avoided thanks to PostSharp, we added a nice tool window in Visual Studio.

From now on, the team is working on PostSharp 4.3. Make sure you check our roadmap to see what’s coming next.

Happy PostSharping!

-gael

We are done! After 10 months of development, the team is happy to announce that PostSharp 4.2 is now fully finished, tested and documented, and since we reached a zero-known-bug status, we’re more than relieved to say that the RC quality level has been reached. We don’t make a difference between RC and RTM quality level, which means that we consider PostSharp 4.2 to be ready, just needing more end-customer testing.

You can download PostSharp 4.2 from our website or from NuGet (make sure to enable the pre-release option as usually). The documentation is available for download but not yet for online browsing.

What’s New in PostSharp 4.2?

In the previous blog posts (see Preview 1, Preview 3 and Preview 4 announcements), we announced the following features:

  • Full support for Visual Basic;
  • Ready-made patterns: amazing performance improvements;
  • Ready-made patterns: support for System.Collections.Immutable;
  • Ready-made patterns: support for programmatic rules;
  • Thread-safety policy;
  • INotifyPropertyChanged: support for INotifyPropertyChanging;
  • Module initializers;
  • OnAspectsInitialized advice;
  • Code metrics: hand-written code and code saved by PostSharp;
  • Customizable advice descriptions.

Today, we are announcing the following new features:

  • Support for ASP.NET v5;
  • NotifyPropertyChanged: support for Elvis operator and conditional branches;
  • NotifyPropertyChanged: method to manual raise OnPropertyChanged / OnPropertyChanging;
  • NotifyPropertyChanged: basic support for dependencies on collections;
  • Code Contracts: check output values;
  • Fixed debugging experience in async methods;
  • Actor: support non-async methods returning a value.

Experimental Support for ASP.NET v5

Even if ASP.NET v5 is still preview, we are already providing some experimental support for it. Given the high fragility of ASP.NET v5 public APIs, we are shipping the ASP.NET v5 connector in a separate open-source project named PostSharp.Dnx, hosted on GitHub. Please look at the project home page for instructions.

This experimental connector only supports the .NET Framework, i.e. neither CoreCLR nor Mono is supported.

Note that our plan is to merge PostSharp.Dnx into our main PostSharp package when ASP.NET v5 and the PostSharp connector will be more stable.

To make it possible to open-source the DNX connector, we had to publish a new NuGet package named PostSharp.Compiler.Client, which defines an API to invoke PostSharp. The MSBuild connector now also uses PostSharp.Compiler.Client.

Improvements to NotifyPropertyChanged

Support for Elvis operator, conditional expressions and more

Since the beginning, our NotifyPropertyChanged aspect has supported chained dependencies (when a property depends on a property of a property). With PostSharp 4.2, we will not only support the dot operator, but also the Elvis operator. Consider the example below:

[NotifyPropertyChanged]
class CustomerViewModel
{
    public CustomerModel Model { get; set; }

    public string FullName 
{
get
{ return string.Format("{0} {1} from {2}", this.Model?.FirstName, this.Model?.LastName,
this.Model?.Address?.City); }
} }

Note how the FullName property depends on the this.Model?.Address?.City chain. This is a very common scenario in MVVM applications, but it is generally very cumbersome to implement INotifyPropertyChanged in this situation. This is why PostSharp is so useful here. Unfortunately, this was not possible in PostSharp 4.1 because of the Elvis operator. We fixed that in PostSharp 4.2.

It apparently seems like a small change, but because we are analyzing MSIL and not C#, we actually had to add support for conditional branches and local variables. I will skip the full technical details, but basically we support the following kind of constructs:

[NotifyPropertyChanged]
class AddressFallback
{
    public Address Address1 { get; set; }
public Address Address2 { get; set; } public string City
{
get
{ return (this.Address1 ?? this.Address2)?.City; }
} }

In the example above, PostSharp would detect a dependency from AddressFallback.City to both Address1.City and Address2.City. If we would have expressed the same logic with ?: or an if-else, PostSharp would have detected the same dependencies as well.

Raise OnPropertyChanged and OnPropertyChanging

These methods are named SignalPropertyChanged and SignalPropertyChanging and they are exposed on the NotifyPropertyChangedServices class.

Dependencies to collections

When you add the [AggregateAllChanges] attribute to a field or automatic property, any change to a property of the object assigned to this field/property will be interpreted as a change to the field/property itself. The attribute now works only for collections.

Code Contracts: output parameters and return values

You can now add a code contract to the return value of a method or to its out/ref parameters. The code contract will be verified when the method returns (not on exception).

For instance, you can do this:

public interface IFoo
{
[return:Required]
string GetName();

void GetName([Required] out string name);
}

Actor: support for non-async methods returning a value

We are now allowing non-async non-void methods on actors. The method will be executed on the actor’s message queue but the caller will wait synchronously for the method execution to complete. Exceptions are dispatched to the caller.

This introduces an ambiguity with the behavior of non-async void methods, because the previous behavior was to execute them asynchronously, without requiring the caller to wait for the result. To resolve the ambiguity, we now require non-async void methods to be explicitly annotated with the [Dispatched] custom attribute. In the next major version, we will remove this requirement and non-async void methods will be called synchronously (but executed on the actor queue).

Summary

PostSharp 4.2 is a huge release, with major usability and performance improvements in many existing features. We’ve put the quality bar very high for this RC and we are pretty confident that the roll up will be smooth.

As with any RC, we suggest that customers test the new release in a separate branch of their source repository, run the build and the tests, and report any problem found. The whole point of publishing an RC is to gather customer feedback, and by reporting issues you are contributing to make the RTM better.

Thank you, and Happy PostSharping!

-gael

We’re excited to announce the launch of the PostSharp Consulting Partner program, an initiative designed to increase our cooperation with IT consulting and custom development companies.

If you build software for your customers, the PostSharp Consulting Program is for you!

Everybody starts at Gold level. As an entry gift, each partner will receive a free PostSharp Ultimate license and then a 40% discounts on the first 5 licenses purchased for your team. Additionally, you will be able to purchase additional licenses for yourself and your customers with a reseller-grade discount.

As a consultancy, PostSharp helps you deliver high-quality applications at lower cost and faster so that you can close more deals and meet your deadlines. Sure, there is no silver bullet, and software engineering will always be hard work. But PostSharp allows you to avoid writing repeating code – and the effort and defects that come with it.

In exchange of the discount, we at PostSharp expect to have tight communication with our partners. We want to hear from your projects, from your successes with PostSharp, and from your difficulties. And because we take it seriously, we are offering free technical consulting (reasonably - until supplies last) with an engineer (actually with me in the beginning).

To learn more about this program, visit our PostSharp Partner Portal.

Happy PostSharping!

-gael