I am pleased to announce the final release of PostSharp 2.0.
This release occurs almost one year after the initial prototype of PostSharp 2.0, and 9 months after the first public CTP. Since then, the number of monthly downloads of PostSharp 2.0 has largely exceeded the one of PostSharp 1.5. PostSharp 2.0 is already being used by dozens of commercial customers and all issues reported during the pre-release period have been addressed. Therefore, it’s with great confidence that I recommend everyone makes the upgrade from any previous version of PostSharp, including 1.5 and 1.0.
Why Upgrading from PostSharp 1.5?
PostSharp 1.0 and 1.5 made aspect-oriented programming (AOP) popular in the .NET community.
PostSharp 2.0 makes it mainstream by enhancing convenience (Visual Studio Extension), reliability (dependency enforcement), run-time performance (optimizer), and features (composite aspects, property- and event-level aspects).
New features of PostSharp 2.0 over 1.5 include:
- Visual Studio Extension – for easier code reading
- Composite Aspects (Advices and Pointcuts) – for more powerful aspects
- Adaptive Code Generation – for better runtime performance
- Aspect Dependencies – to prevent conflicts between aspects in large projects
- Interception Aspects for Fields, Properties, and Events
- Instance-Scoped Aspects
- Build-Time Performance Improvements
For a detailed list of these features, see What’s New in PostSharp 2.0.
How To Upgrade from 1.5?
PostSharp 2.0 contains a library called PostSharp.Laos.dll. This is an emulation layer, and is meant to be used during the migration of 1.5 to 2.0. When you’ll build your project, you’ll get a lot of obsolescence warnings. When all these warnings are gone, you can remove the PostSharp.Laos.dll reference from your project. It’s only after complete migration that you will see improvements in runtime performance.
What’s New Since RC2?
The following issues were fixed:
- Invalid code generation when two MethodInterceptionAspects are applied on a method containing an anonymous method.
- Invalid code generation for pointer types ('valuetype' or 'class' keyword missing)
- Invalid code generation when an interception aspect is applied to a method containing a '.constrained' prefix
- Invalid code generation when multiple MethodInterceptionAspects are applied to a generic method
- When a method-level aspect is applied to an interface, it is not multicast to interface methods
- ILASM failure with symbol sequence points with a document but without a column
- KeyNotFoundException from MulticastAttributeTask.ImportCustomAttribute
A small breaking change was introduced to solve some well-definedness issue with aspects applied on abstract methods: when applying an aspect to a type or member defined outside the current project, use:
- MulticastAttribute.AttributeTargetExternalTypeAttributes instead of MulticastAttribute.AttributeTargetTypeAttributes
- MulticastAttribute.AttributeTargetExternalMemberAttributes instead of MulticastAttribute.AttributeTargetMemberAttributes
I would like to express special thanks to all people who helped during the pre-release period and to all companies who acquired licenses before the product was labeled as stable. I highly appreciate your support, and have a great confidence in the future of PostSharp and SharpCrafters.
Where to go next from here is not yet decided, but we’ll be working quite soon on a minor release. Most importantly, we’ll start real marketing and we’ll scale the company by hiring the best developers we can find.
From today, it will be easier to use PostSharp 2.0 in open-source projects. Indeed, the revised license includes a limited, but quite universal, redistribution license: any user, even of the community license, has the right to redistribute PostSharp.
Redistribute means just that: copy, or upload on a public server. Of course, it does not mean that you can grant somebody else the right to use PostSharp – otherwise we could immediately file for bankruptcy. But it does mean that you can include PostSharp in your public source repository, so anyone can build your project without installing PostSharp separately.
Even better: Users of your OSS project will not need to acquire a license of PostSharp. They will just check out the source code and it will build.
How does it work?
If you own an OSS project and want to use PostSharp in it, contact me. Give a brief explanation of what your project does. Tell your root namespace and the strong name public key token.
If your project qualifies (it must not compete with PostSharp itself, obviously), I will answer with an assembly license key. This license key is is bound to your root namespace and your public key token.
Create a text file named PostSharp.license and paste the license key. Include this file as a managed resource in the project containing the aspects. From this moment, all aspects contained in your project (if the namespace and the public key match) will be authorized, irrespective of the license entered by the user.
That’s how things are solved from a technical point of view. For the details of the legal point of view, please read the revised license agreement.
Please comment here if you have any question regarding this license.