PostSharp

As the first stable version of PostSharp has been released for one month, a question arose:

What feature or bug fix is important to you, community? In other words, where should we put our effort?

Finally I’ve set up a feature voting system: you can vote for a bug or a feature, therefore giving it higher priority. The system is based on ‘coins’. Once you create an account on www.postsharp.org, you get 10 coins (existing accounts have been credited of 10 coins as well). You can attribute them to the features of your choice. So you can already start voting immediately!

If you donate to the project, you receive an additional coin for each euro you gave. It does not mean that 1 coin has a value of 1 euro, because I also attribute donations to past efforts and to operational expenses of the project. So to give you an idea, even if coins are not real money, I consider that 1 hour of development should be covered by 100 coins. (Indeed, maintaining and developing PostSharp costs me thousands of euros per month…)

After you make a donation using PostSharp, you will receive an email with a link to a page allowing you to connect the coins. This page requires you to be logged in, so your donation will be assigned to your account.

There is no trick. Coins are not contractual; they are just a way for you to tell me what is important to you, and for me to tell you that the lunch is not free for everyone.

That being said, if you want to make a more significant donation (say >1000 EUR), we can negotiate something contractual, i.e. we discuss what feature will be realized and when. If you are interested by this option, please contact me. For even bigger sponsors, I will set up a partnership program, so you could get the nice status of “PostSharp Silver Partner”. Wow!

Anyway. Even if you are not to donate, you are already welcome to vote for features now!

Happy PostSharping!

-gael

The days where AOP was limited to the academic samples of tracing and authorization are definitely over!

Szymon Pobiega has released PostSharp4ViewState on CodePlex. This PostSharp plug-in defines a new custom attribute [Persist]. When you apply it to an instance property of an ASP.NET page of control, it will simply… persist it in the state view!

Under the hood, PostSharp4ViewState implements the methods LoadControlState and SaveControlState.

For more information, please read the PostSharp4ViewState Code Project article. And don’t forget to give him a good vote ;-).

Thank you Szymon for this great plug-in, and congratulations!

-gael

We have just doubled the amount of RAM available to the PostSharp server.

Guess what is the server configuration? What do you think a Microsoft-centric open-source project runs on?

Well… a Linux/Debian virtual server (Xen) running Apache, Mono, phpbb, wordpress, mantis and htdig! Daily backup using rsync. Try to have the same feature for less than 35 EUR a month on Windows!

-gael

An untraditional aspect of the PostSharp activist Michal Dabrowski:

People who use NHibernate know that in order to take advantage of its lazy-loading facility, all public members of the persisted classes must be marked as virtual. Compared to all the benefits the lazy-loading brings, this seems to be a very insignificant price. However, for some people, including me, this extra virtual keyword is still some annoyance. It is very easy to forget about it when writing a new code, it makes Resharper complain sometimes (”virtual member call in constructor” warning) and it is ugly (subjective one, I know). In this article I would like to show how to solve these issues with a simple aspect, that makes members virtual even if the keyword is not used in the source code.

Read the complete article on Code Project.

I’ll give a 2-hour presentation of PostSharp for the user group SweNug in Stockholm, Sweden, on September 23th, 2008. Details here.

I’ll stay the whole week in Stockholm and have usually nothing to do in the evening, so if you always wanted to meet a real geek, don’t hesitate to ping me!

-gael

Four years after the project’s initiation, I have been honored last Tuesday in Prague (Czech Republic), in PostSharp’s home country, to announce the availability of the first stable release. This release can be download from our download section.

Although everyone knows that a software of this complexity is never completely bug-free, the last release candidate has been very stable and all fixes required only minor, local and safe modifications.

The 1.0 branch now becomes a legacy branch. It will further maintained as long as another branch does not reach a higher level of stability.

This version is therefore one you can rely on.

Happy PostSharping!

-gael

Alex Yakunin from x-tensive.com announced yesterday the release of DataObjects.NET 4.0, the first commercial product relying and distributing PostSharp.

Cooperation with X-tensive.com started two years ago; they were the first commercial company that chose to rely on PostSharp for their flagship product. We have worked together to fix bugs and add features in these still early days.

The project was difficult and ambitious, deadlines have been often postponed, and I am happy to see that the project finally went out!

DataObjects.NET 4.0 is released under GPL and commercial licenses.

Congratulations to all, and specially to Alex and Denis with whom I have been communicating a lot last year!

Happy PostSharping!

-gael

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

Good luck Simon!

-gael

Users often ask if it is possible to use PostSharp at runtime, so aspects don’t have to be known at compile time. Changing aspects after deployment is indeed a great advantage, since it allow support staff to enable/disable tracing or performance monitoring for individual parts of the software. One of the cool things it would enable is to apply aspects on third-party assemblies.

If you ask whether it is possible, the short answer is yes! Unfortunately, the long answer is more complex.

Theoretically, it should be possible to transform assemblies before they are loaded by the CLR. The idea is to develop a kind of bootstrapper, or host, that transforms all relevant assemblies before the CLR need them. PostSharp has been designed to be used with such bootstrappers. So you can perfectly invoke PostSharp from your application. The most typical scenario is when you develop an extensible application that loads "user assemblies", like an application server may load user applications, or like any other application may load plug-in. Basically, in this scenario, your application is the master, and user code the slave. The master can define rules slaves should follow; slaves are only partially trusted and some code should be transformed. For instance, in an application server providing persistence, persistent objects of user applications will be transformed so that fields are transformed to database slots, and accesses to fields to accessed to these slots.

So when your code is in charge and can impose a fairly large set of restrictions on transformed assemblies, it is technically feasible to host PostSharp. There is a special hosting API for this purpose. PostSharp comes with two build-time hosts: the MSBuild task the command-line utility. It also comes with a sample demonstrating how to make a runtime host; this sample transforms all assemblies in the closure of the entry assembly.

So now, what are the gotchas?

• Plugging the bootstrapper. If your code is hosted (for instance in ASP.NET or in a COM server), you cannot plug the bootstrapper. So any runtime weaving technology is bound to the limitation that you should host the application yourself.
• Be Before the CLR. If the CLR finds the untransformed assembly by its own, it will not ask for the transformed one. So you may need to create a new application domain for the transformed application, and put transformed assemblies in its binary path. It’s maybe not a big problem.
• Strong names. Ough. If you modify an assembly at runtime, you will have to remove its strong name. Will it work? Yes, mostly. Of course, you have to remove the strong names from all references to this assembly. That’s not a problem; PostSharp supports it out-of-the-box. But there is something PostSharp cannot help with: if there are some strongly named references in strings or files (for instance in app.config), we can hardly find them and transform them. So here we have a real limitation: there cannot be "loose references" to strongly named assemblies: we are only able to transform real references.
• LoadFrom: If any assembly uses Assembly.LoadFrom, Assembly.LoadFile or Assembly.LoadBytes, our bootstrapper is skipped…

There may be a lot of circumstances in which these limitations don’t matter. However, they are a sufficient reason not to develop an all-purpose bootstrapper. In other words, there is no one-size-fits-all bootstrapper.

Real CLR geeks know that the CLR itself can be hosted and its assembly loading mechanism can be customized. Couldn’t it be used to transformed assemblies on the fly? Yes, but it would not help that much, because:

• We still have to host the application ourselves.

• This time we don’t have to be before the CLR; we can do it on-the-fly.

• We still have to remove strong names. Unfortunately, we cannot kindly ask the CLR to ignore strong names for the assembly we provide.

• If we customize the assembly loading mechanism, we simply disable Assembly.LoadFrom, Assembly.LoadFile, Assembly.LoadBytes. So no JIT-emitted serializers, no compiled regular expressions, …

So in a few words: if you are developing anything that looks like an application server, runtime PostSharp is for you. Otherwise, it’s better you forget about it and read about specific runtime technologies like the profiling API.

Happy PostSharping anyway!

-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