PostSharp

Simon Stewart will present PostSharp at Port Elizabeth in South Africa.

Good luck Simon!

-gael

Gnanasekaran’s study rates PostSharp first with a 95% score! PIAB and Spring.NET come second and third.

Although the source is not very authoritative and has a pretty restricted set of comparison points, I hope there is at least some truth under PostSharp’s pole position :-).

Happy PostSharping!

-gael

Yet another blogging about AOP blogging? This time, read further.

I know logging is the Hello, world! sample of aspect-oriented programming. It is the sample on the home page of www.postsharp.org, and many have blogged about that. However, all solutions I’ve seen so far use PostSharp Laos…

The problem with Laos is its impact on performance. Although it performs similarly or better than other AOP solutions, it cannot be compared to inlined code. And that’s what Log4PostSharp does: it inlines logging instructions into your method body. Parameters are not boxed, no "eventArgs" object is created, no external aspect class is involved. Just pure instructions.

I almost forgot the most important: Log4PostSharp uses log4net as the backend.

Among the sweets you’ll find: a quite powerful system to set up the logging string like {signature} or {@parameter_name}. All evaluated at build time (unless parameter values of course)!

The project is available under BSD license. A great work of Michal Dabrowski!

That’s enough for me. For more info, please read Michal’s introduction to Log4PostSharp.

Happy PostSharping!

-Gael

Next month I’m back in Poland, this time in Warsaw. I’ll be present at the Zine Day 2008. Once again, I will be in excellent company with András Belokosztolszki, principal architect of RedGate.

I have two sessions. The first will introduce aspect-oriented programming in general and will compare four frameworks: PostSharp (of course), Spring.NET, Castle, and Microsoft PIAB. This is a tough session, but I have a good time slot (9h-10h15). The second session will be very interactive. Together with Jakub Binkowski, I will demonstrate simple and advanced features of PostSharp Laos on a real application.

See you there!

-Gael

Jestli to ještě nevíte, PostSharp je český projekt. Ano, ikdyž je autor Belgičan, už dávno bydlí nedaleko Prahy.

9. září 2008 budu prezentovat PostSharp v Praze od 18. do 20. hodiny u Microsoftu. Přednáška bude česky s roztomylým Belgickým přízvukem.

Detaily najdete na http://akce.altairis.cz/Events/194.aspx. Registrace předem je nutná.

-Gael

I have an article available for publication for national audiences only. This means that the article should either be translated into a local language (anything but English), either distributed to a closed community (subscribers only).

If anyone is interested, please contact me. And if you want your favorite magazine to publish something about PostSharp, forward them this page :-D.

-Gael

P.S. The article is great!

In my previous post I claimed that it was not possible, in general, to merge assemblies enhanced by PostSharp, because it would break the assembly references stored as strings in aspect serialization data.

I did not realize that the BinaryFormatter provides a way to solve our problem. It is indeed possible to provide its own SerializationBinder, whose role is precisely to return the System.Type corresponding to an assembly name and a type name. We can provide a custom binder to redirect merged assemblies.

This is the feature I have added to build 1.0.10.411 available for download in the builds section; I could still do it in 1.0 since it is a no-risk feature, breaking nothing existing (if you don’t use it, nothing can go wrong).

I have added a new class PostSharp.Laos.LaosSerializationBinder. You can set the static property Current to your own implementation of SerializationBinder. If you don’t set it, nothing is changed. The LaosSerializationBinder class it itself derived from SerializationBinder and implements the feature we need: assembly retargeting. So all you have to do is to create an instance of this class, set up retargeting policies, and assign it to LaosSerializationBinder.Current.

The following code sets up PostSharp Laos so that references to ‘MergedPostSharpLib.dll’ are retargeted to ‘MergedPostSharp.exe’ (supposing that the library has been merged into the executable):

LaosSerializationBinder binder = new LaosSerializationBinder();
binder.Retarget("MergedPostSharpLib", "MergedPostSharp");
LaosSerializationBinder.Current = binder;

The only thing you have to really take care about is to set up the binder before the first aspect is deserialized. Aspect deserialization is triggered from static constructors of enhanced classes, so you may need to initialize the weaver very soon, and eventually to refactor your "Main(string args[])" method.

Apart from that, it should work very well.

Happy PostSharping!

~Gael

Combining PostSharp with ILMerge seems a recurring demand. Indeed, many developers don’t welcome the multiplication of dependent assemblies as PostSharp.Public.dll and PostSharp.Laos.dll, and ILMerge seems the dreamed solution to that. Unfortunately, it will work only in rare cases.

The Simple Case

Say you have an assembly named MyProgram.exe with aspects defined in this assembly. The application is formed of the following assemblies:

PostSharp.Public.dll
PostSharp.Laos.dll
MyProgram.exe

In this particular case, it is valid to merge all three assemblies into a new assembly equally named MyProgram.exe.

However, if you modify the name of the merged assembly, it will cease to work.

What’s Wrong?

Remember that the aspects are serialized into the assembly. It uses the BinaryFormatter to do the job. Unfortunately for our purpose, this formatter stores the full type name of aspects, including the assembly name. So when you rename the assembly, you break the link between the aspect serialization and the underlying types, and you get an exception during deserialization.

The same occurs when you have aspects in one of the dependencies you merge. Say your program references MyLibrary.dll, whose some classes have been enhanced by PostSharp Laos. If you merge it into MyProgram.exe, the serialization of aspects previously defined in MyLibrary.dll will be broken.

Possible Solution

The problem clearly lays in the use of the BinaryFormatter to do the job. We could eventually use another serializer that does not store the full type name.

This feature (pluggable serializers) was actually present in former builds of what is now PostSharp 1.5, but I have removed the feature because it became useless. If there is some interest, I could restore it. It very much depends on the feedback I will get.

How is this a critical feature for you?

Happy PostSharping,

~Gael

Now that PostSharp 1.0 is pretty stable and anyway virtually frozen, I am pleased to announce that the first community technical preview of PostSharp 1.5, the current living branch of PostSharp, is now available for download.

This CTP makes a great leap forward in supporting more platforms:

• Novell Mono. PostSharp now run on Mono and has been tested both in the Windows and the Linux implementation. PostSharp is now truly cross-platform, since the same PostSharp executable can now run on any platform.
• Microsoft Silverlight 2. Who said aspects are only for server applications? Thanks to PostSharp 1.5, you can now apply aspects to your projects targeting Silverlight 2.
• Microsoft .NET Compact Framework 2.0.

Enlarging PostSharp support to these platforms required the possibility to read and transform assemblies without loading them in the CLR. Therefore, one of the hidden new features of PostSharp 1.5 is the ability to read assemblies directly from disk.

Another hidden feature is the support for assembly retargeting, which happens when an assembly reference is resolved to an assembly of higher version than was required. This feature, supported by the .NET framework, was missing in PostSharp. This first CTP offers a first yet incomplete solution to this issue.

The documentation and samples have been updated to include support for Silverlight and the Compact Framework.

Note that PostSharp 1.5 is not fully compatible with PostSharp 1.0. End-users should not see the difference, but if you played with PostSharp Core or with some advanced features of PostSharp Laos, your code will need some changes.

Happy PostSharping!

~Gael

PostSharp 1.0

Most people think of PostSharp as a new product, but PostSharp is actually near to 4 years old. The first bits were indeed developed in September 2004. It took roughly 2 years to develop the product and 2 years to stabilize days. Attentive users have maybe noticed the last RC of PostSharp has the full version number 1.0.10.403. 10 means that it is the 10th release of the 1.0 branch. 403 is the revision number of the root of that branch in source control.

Today the 1.0 branch is very stable. There has been no major change and so significant feature addition for one year. It is being downloaded more than one thousand times per month (still quite a modest number). So the future of the 1.0 branch is clear: fix bugs and declare the branch stable. More a marketing operation than a technical one.

The 1.0 branch will remain a legacy one. Bugs will continue to be fixed, support will be provided. So it is definitively a product you can rely on.

PostSharp 1.5

In October 2007, I forked the 1.0 branch into 1.1. Unfortunately, I had to interrupt the work, principally because much work was still required on 1.0, and on the web site. Good news is that I resumed work around last April and made good progresses.

Since this new branch contains major new features, I chose to number it 1.5.

The objectives of this branch are triple:

1. Enlarge supported platforms to Mono, Compact Framework and Silverlight 2 [CTP 1, July 2008].
2. Implement frequently asked feature [CPT 2, August-Sep 2008]
3. Allow aspects to be inherited (for instance, if you apply an aspect on an interface, the aspect will be applied to all types implementing it) [CPT 3, Sep-Oct 2008].

After the cycles of CTP, there will be a cycle of Beta releases during which features will be added according to the feedback got during CTP. Then release candidates and hopefully RTM.

A characteristic of 1.5 is that it won’t be fully compatible with 1.0. End users (those writing aspects using PostSharp Laos) should not see a big difference and most of their existing code should still work, but some minor changes are to be expected for Core developers. Not a big deal, but it’s better to know it.

Design by Contract

PostSharp 1.5 will provide the basic bricks necessary to build a real design-by-contract (tm, I know) framework. I still don’t know exactly what it will contain, but you can obviously expect the non-nullable references and similar value constraints, including a mean to do your own validators without the burden of PostSharp Laos. But the framework should be more ambitious than just value checking. Invariant checks and defense (eventually in a multithreaded context) are on the wish list.

A first version will be available in November 2008.

I have no plan for 2009, but I guess it will be determined by your feedback on these new features.

Happy PostSharping!

~Gael