Announcing PostSharp 2.1 CTP 1

As any CTP, this release is meant for testing and not for production use.

PostSharp 2.1 is a minor upgrade to PostSharp 2.0, which means that your existing license key should just work.

What’s New in PostSharp 2.1 CTP 1?

This first CTP is all about improving build-time performance, i.e. making PostSharp compile faster.

Much faster.

Here are the results measured by Bartek Legiędź and Remigiusz Cieślak, software engineers at Comarch in Poland. Their setup consists of a small number of very large projects (assemblies of several megabytes). As you can see, PostSharp 2.1 is more than five times faster than 2.0.

The next table compares the time taken by PostSharp while building the solution in two configurations (debug and release). Of course PostSharp itself ran in release mode both times.

Thanks guys for your time doing this benchmark!

The performance improvement you will experience with your setup depends on several factors: size and number of projects, number of aspects, and hardware resources. Also, remember that PostSharp is only a part of the build process. After upgrading to PostSharp 2.1, the build time may be dominated by the C# compiler or by Code Contracts.

I would like to hear about your own experience of performance improvements.

Here is how to produce benchmark results:

1. Wait until the system load is stably low (TortoiseSVNCache.exe and similar processes may load your processor)
2. Execute: Msbuild /p:Configuration=Debug /clp:PerformanceSummary /t:rebuild > msbuild-2.0.log
3. Upgrade your project to PostSharp 2.1 (see below)
4. Execute: Msbuild /p:Configuration=Debug /clp:PerformanceSummary /t:rebuild > msbuild-2.1.log

The performance report lays near to the end of the log file, above the summary of warnings and errors. For greater accuracy, you should execute MSBuild three times with every version of PostSharp, and take the best results. Then you can send me both performance summaries by email (gael@sharpcrafters.com) so I can see how large are improvements with real-life projects. Frankly, I don’t expect 500% improvement for everybody.

What Changed in PostSharp 2.1 CTP

Most performance improvements were obtained by replacing the component that writes back the assembly to disk. Before version 2.1, PostSharp still used  our ol’ good text-based writer, backed by Microsoft’s ILASM. This required a lot of I/O just to create the text IL file (some customers reported files of several hundreds of megabytes), then ILASM required a lot of CPU and memory to process it. Fortunately, this was not that bad and there were excellent reasons to keep this writer. Now we have our own assembly writer, coded by your servant himself, and tuned with all the obsession and passion he is able of.

You should normally not observe any difference from PostSharp 2.0, except of compilation speed. Debugging support may be a little improved because I integrated some bits of the Microsoft CCI PDB reader/writer into PostSharp, but this debugging support is still to be fine-tuned.

So except this, there’s no change in this CTP, no addition of feature.

Redefinition of the Community Edition

The Community Edition is being renamed Starter Edition, because the former name did confuse many people.

We’re doing two little changes in the features available to the Starter Edition:

• The Aspect Dependency Framework (PostSharp.Aspects.Dependencies) will not be available any more in the Starter Edition. Frankly, this feature was present by mistake, since it clearly supports “pro” scenarios. To order aspects, Starter users will have to use the AspectPriority attributes, i.e. they will have to assign an integer to every aspect.
• The Starter Edition will not run from source control. It will have to be installed on the computer.
• Yes, the new build-time performance enhancements are available to the Starter Edition!

So we add a lot and we remove a little in order to position the Starter Edition as a light tool for individuals, and the Professional Edition as – well -- a professional tool for teams. We do not push anyone in the corner. You all have workarounds: installing the product or using AspectPriority. We are just getting clearer about the positioning of each edition. We think we’re adding more comfort to the Starter Edition than we actually remove.

And remember: PostSharp is cheap (usually less than one day of bill), and we give a lot of discounts to students, Microsoft BizSparks members, or influencers.

Upgrade to PostSharp 2.1 CTP

PostSharp 2.1 CTP can be installed side-by-side with PostSharp 2.0 on the same machine. At build time, the correct version of PostSharp should kick in, according to the version of PostSharp.dll your project is referencing.

There is one exception to this rule. The Visual Studio Extensions (VSX) cannot be installed side-by-side, so the setup program of PostSharp 2.1 will remove the VSX of PostSharp 2.0 and replace it by the new version. Since it’s backward compatible, the VSX 2.1 will work with projects using PostSharp 2.0.

Once you’ve installed PostSharp 2.1 (or copied it to your source control), you can run the PostSharp 2.1 Conversion Utility (PostSharp.Convert.exe), a simple application that let you update your references from previous versions to the current one. The utility is also able to prepare your project to run PostSharp from source control, if you prefer not to install it using the setup program. Note that all this utility does is to edit your csproj or vbproj files.

Gotcha: When a project references both PostSharp 2.0 and 2.1

What happens if you have a project that has been migrated to PostSharp 2.1, but uses a component (such as Gibraltar aspects) that has not been? The project would have a direct reference to PostSharp.dll version 2.1, and an indirect reference to PostSharp.dll version 2.0.

1. Make sure that the old PostSharp.dll dependency is not copied to your final bin directory. At run-time, you will need the version 2.1.
2. Install the last hot fix of PostSharp 2.0.
3. Add the following code to your application configuration file:

<configuration>
  <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
        <assemblyIdentity name="PostSharp" publicKeyToken="b13fd38b8f9c99d7" 
                          culture="neutral"  />
        <bindingRedirect oldVersion="2.0.0.0" newVersion="2.1.0.0"  />
      </dependentAssembly>
    </assemblyBinding>
  </runtime>
</configuration>

Therefore, our partners don’t need to recompile their product for every of our minor version, and you can always use the version of PostSharp you would like.

What’s Next?

We did our best to address the major painful point reported by users: building time. We tested the new PE writer on large and complex assemblies like those forming the .NET framework itself. Now we want to hear from you:

• Does it work for your projects?
• What are the performance gains?

In the mean time, we’ll be working on the next CTP, which should bring some minor new features. Then there’ll be the cycle of RC and finally the winner RC will be promoted RTM.

Happy PostSharping!

-gael