Archive

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

Comments (4) -

Mike-EEE
Mike-EEE
12/9/2015 12:52:28 PM #

This is really awesome news, Gael!  

I am glad to see the updates with threading and all the new components/collections.  I will definitely be looking into this.

I am curious since this deals with asynchronous programming if this also addresses the idea/suggestion here:
postsharp.uservoice.com/.../7186171-help-cleanup-the-async-mess-in-current-net-kill

Additionally, food for thought here: one thing that pops up here personally is Community/Open Source support.  I currently run an open source project that has flirted with the idea of using PostSharp.  In fact I did use it for a while, but removed it.  The problem is that if I force my end users to use it, they will be paying hundreds of dollars and I do not think that is fair to them.

I really like PostSharp and am a huge supporter.  However, the pricing model is prohibitive and I think some of your innovative thinking should go into how community efforts can leverage it and help spread the love/value without paying through the nose.

Perhaps something like what MSFT has done with Community vs. Enterprise models?

Anyways, something to think about.  I would love to use PostSharp in my open source project in confidence, but these are my thoughts around it.

Thanks for any feedback/thoughts and congratulations again on this release!

Gael Fraiteur
Gael Fraiteur
12/9/2015 3:55:03 PM #

Thank for your comment, Mike.

1. Regarding the async mess cleaning: I can see the value of doing that, but it would be very complex to do it properly. Currently we are not looking into this but we keep the feature request opened for voting.

2. Regarding open-source support: we do offer free open-source licenses, where the license key can be added to the compiled assembly or source control. People who compile or use your library don't need a license key. Many projects are using this possibility: see https://www.postsharp.net/community. You can ask a license key for your projects.

3. VS Community Edition: currently we don't think we are in financial position to make PostSharp free for small companies. PostSharp is already free for freelancers, it's almost free for students (and it's free if you ask kindly), and have big discounts for startups and other categories. See https://www.postsharp.net/purchase/discounts.

I hope this answers your concerns and questions.

-gael

Mike-EEE
Mike-EEE
12/9/2015 7:14:26 PM #

Whoa!!  I totally misunderstood how your open source works.  That is AWESOME.  Thank you so much for doing that.  I will be utilizing PostSharp then. :)

Thank you also for the informative answers.  Excited to use PostSharp.

Mike-EEE
Mike-EEE
12/9/2015 7:17:17 PM #

Although... I am a little disturbed that I am really the only person who hates zombie code in my solutions.   The zombies have taken over and are here to stay. :P

Comments are closed