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

Pingbacks and trackbacks (1)+

Comments are closed