Archive

I am pleased to announce the third and last preview of PostSharp 1.5, available for download today.

Its most exiting feature: it is twice faster than PostSharp 1.0! PostSharp 1.5 CTP 3 includes all bug fixes of PostSharp 1.0 SP1. Except performance, this release does not bring any new feature, but went through some refactoring to solve design problems of CTP 2, and documents new features.

For those who still use 1.0, here is a summary of new features of 1.5:

Reading assemblies without loading them in the CLR
In version 1.0, PostSharp required assemblies to be loaded in the CLR (i.e. in the application domain) to be able to read them. This limitation belongs to the past. When PostSharp processes a Silverlight or a Compact Framework assembly, it is never loaded by the CLR.

Lazy loading of assemblies 
When PostSharp has to load a dependency assembly, it now reads only the metadata objects it really needs, resulting in a huge performance improvement and much lower memory consumption.

Performance optimizations
The code has been carefully profiled and optimized for maximal performance.

Support for Novell Mono
PostSharp is now truly cross-platform. Binaries compiled on the Microsoft platform can be executed under Novell Mono. Both Windows and Linux are tested and supported. A NAnt task makes it easier to use PostSharp in these environments.

Support for Silverlight 2.0 and the Compact Framework
You can add aspects to your projects targeting Silverlight 2.0 or the Compact Framework 2.0. 

Pluggable Aspect Serializer & Partial Trust
Previously, all aspects were serializer using the standard .NET binary formatter. It is now possible to choose another serializer or implement your own, and enhance assemblies that be executed with partial trust. 

The next release will be a release candidate; expect it in 1-2 months according to the pace of bug reports.

Happy PostSharping!

-gael

Comments (4) -

Christian Nielsen
Christian Nielsen
2/23/2009 11:23:29 PM #

One feature i am missing badly is the ability to access arguments by their name. This is possible when using Interceptors in Castle Windsor and in a lot of cases it seems like the better choise. Windsor og course has its own limitations, but if I could get this in PostSharp i would definately see myself using it more.

Gael Fraiteur
Gael Fraiteur
2/24/2009 9:56:37 AM #

In my opinion, the aspect should not be aware of the names of parameters.
But if you want it anyway, you can always find the parameter index from its name by using reflection. And if you don't want to use reflection at runtime, you can do it at compile-time using CompileTimeInitialize.

If the feature were implemented in PostSharp, people would use it without thinking about performance impac.

Daniel Crabtree
Daniel Crabtree
2/26/2009 2:04:45 AM #

I'm wondering about the statement "twice faster than PostSharp 1.0". Does this mean the generated code is twice as fast, or its twice as fast at compiling?

Gael Fraiteur
Gael Fraiteur
2/26/2009 9:24:05 AM #

This is only build time. There is no change in runtime performance.
This is actually the time spent in the PostSharp task when building the sample PostSharp.Samples.Librarian, measured on my test virtual machine. Loading of dependencies is much faster and less memory consuming than before.

Comments are closed