Archive

We’re excited to announce that PostSharp 3 RTM is now available for download from Visual Studio Gallery and NuGet. After a successful RC cycle, PostSharp 3 now enters the stable quality band and replaces PostSharp 2.1 as our featured version.

PostSharp 3 marks a huge evolution from previous versions. Designed to deliver more value with less learning, PostSharp 3 is now much more than an awesome framework: using simple smart tags in the Visual Studio code editor, you can add to your code ready-made implementations of some of the most common design patterns. Other improvements include first-class support for Windows Store, Windows Phone and Silverlight apps.

Improved Visual Studio Integration

The single most striking feature of PostSharp 3 is its deeper integration with Visual Studio.

For instance, move the caret to the name of a class or a method. Visual Studio will display a smart tag proposing actions that make sense in the current context: apply a threading model, add logging, implement INotifyPropertyChanged, …

 

A wizard then guides you through the configuration of the aspect.

The wizard installs all required NuGet packages and generates the code for you – so you don’t have to study documentation to figure out how it works.

Of course, you can still add aspects to your code the old good way.

Ready-Made Pattern Implementations

While talking to customers, we figured out that the Pareto law also applies to our product: 80% of customers use the same top 20% aspects. We thought we would provide more value to our customers by providing ready-made implementations for the most common patterns. The results are our three first pattern libraries:

Windows Store, Windows Phone and Silverlight

In previous versions of PostSharp, support for alien .NET platforms was quite limited. The raise of Windows Phone and Windows Store stressed the importance of supporting new trends, so we decided to invest in providing first-class support for Windows Store, Windows Store and Silverlight.

I’m very pleased that we could this through Portable Class Libraries.

The first challenge was to develop a portable alternative to the system BinaryFormatter and its  [Serializable] attribute. The result is the PortableFormatter class and its [PSerializable] attribute – an interesting piece of software in itself.

Deployment through NuGet and Visual Studio Gallery

When PostSharp 1 was released seven years ago, it seemed mandatory to have a setup program. Over the years, source control and build servers have conquered the world, changing requirements on deployment of development tools.

Despites important limitations, Microsoft’s NuGet and Visual Studio Gallery are becoming the de-facto standards for deployment of development components and their user interface, so we decide to get aligned with Microsoft’s lead.

We are aware of some negative consequences and will be happy to work with customers who may be affected by this choice.

Subscription-Based Maintenance Model

PostSharp 3 marks also the move from a per-version to a per-year maintenance model, as described in a previous blog post. A maintenance subscription is now included as a mandatory part of the product fee. The maintenance subscription not only gives right to major versions, but also to bug fixes.

We believe that part of our failure to deliver support for Visual Studio 2012 in time was due to our per-version revenue model. The new revenue model will allow us to release features as soon as they are needed, irrespective of the current major version number.

For more information regarding licensing and support, please read our FAQ page or contact our sales team.

Tip: Upgrade Before Summer

PostSharp 3 is now stable and it’s a good time to upgrade. During the next 2 months, the team will be ready to answer your questions and address support issues, without any other big project in the pipeline. We may be a bit slower during the vacation period, so it’s a good idea not to delay the upgrade if you can do it now.

PostSharp 3 is a big turn for our company, and so far we are very happy with the feedback and the businesses we received.

Happy PostSharping!

-gael

It’s official: PostSharp 3 RC was a success and we are scheduling to move PostSharp 3 to the “stable” quality band on May 2nd. That means that, on May 2nd, the stable release of the PostSharp package on NuGet will be version 3.0. Because of the way the NuGet client is implemented and how people usually author their NuGet packages, this day may turn into a little apocalypse for some of you.

Problem 1. NuGet client in Visual Studio

The NuGet user interface in Visual Studio is hardwired to always give you the latest stable version of a Package. There is no way to specify that you want to stay in an old branch. Even if NuGet allegedly supports semantic versioning, NuGet is going to try to upgrade you to a new major version even if it not backward compatible with the old one (semantic versioning says that backward compatibility can be broken when the major version number changes).

However, PostSharp 3 is not fully backward-compatible with PostSharp 2:

  • There are very minor API changes, and
  • You will need to acquire a new license

Action Required:

  • Pay attention when upgrading using the NuGet user interface. 
  • Consider using the NuGet PowerShell console with the -Version flag to specify which version you want to install, for instance:
    Install-Package PostSharp -Version 2.1.7.30
  • Consider using ProGet Client Tools, an alternative to NuGet Client Tools that has not been optimized for for pushing the latest fresh bits to your desk, but to protect your build your breaking changes.

Problem 2. Packages with dependencies on PostSharp

NuGet packages that have a dependency on PostSharp 2 may install incorrectly after the PostSharp 3 release because NuGet is going to install PostSharp 3 instead of PostSharp 2.

Action Required:

To prevent NuGet from installing PostSharp 3, you need to edit your .nuspec file and add an upper bound to the PostSharp version:

<dependency id="PostSharp" version="[2.1,3)" />

That’s it. Happy PostSharping!

-gael

If there’s one topic that is subject to almost religious observance, this is unit testing.

There has been much hesitation in the community about how PostSharp aspects should be tested and how aspects can consume dependencies from a dependency injection container.

Obviously, we have a lot of experience testing aspects. I finally took the time to write down a set of practices that can be used to create efficient tests of aspects. I also show techniques that allow aspects to consume services from a dependency injection container. Last but not least, I publish and document a test framework for aspect build-time logic, especially logic emitting build-time errors and warnings. The framework is derived from the one we are using internally.

More on our online documentation.

Happy PostSharping!

-gael