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:
-
New advice OnAspectsInitializedAdvice invoked after all aspects on the current object have been initialized.
-
Ability to customize the description of aspects and advices in Visual Studio tooltips. See Customizing Aspect Description in Tooltips for details.
-
In the OnMethodBoundaryAspect and related aspects, ability to yield (await) a state machine upon on entry and resume.
-
Module initializers. See Executing Code Just After the Assembly is Loaded and ModuleInitializerAttribute for details.
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