Archive

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

Some of you expressed the wish of to be able to read the PostSharp documentation offline on their tablet or ebook reader, so we did it. Our conceptual documentation is now available as a print-ready PDF document, and looks awesome on screen and paper.

It’s incredible the content renders to 140 pages, and it does not even include the class reference, which is still only available online or for download as a CHM.

But there’s an issue: although it looks like a book, it has been designed as a reference document and is not the best introduction to PostSharp. Online tutorials are still the preferred way to get started, and they are not included in the PDF.

Happy PostSharping!

-gael