PostSharp

I have just checked in a library (actually, only two classes) allowing to use PostSharp in ASP.NET projects. The stuff is hosted at http://code.google.com/p/postsharp-user-plugins/. The reason why it did not work previously is that ASP.NET compilation does not go through MSBuild, so PostSharp was simply not invoked.

Indeed, MSBuild has its own compilation mechanism. Fortunately, it has an extension point that seems just done for PostSharp: the IAssemblyPostProcessor interface. As you may imagine, it allows to post-process the compiled assembly.

So I simply developed an implementation of this interface (one class). The second class is a configuration handler.

Here is how to use this preliminary version of the library (from the documentation):

In order to use PostSharp in a web project, specify this class as an assembly post-processor in web.config:

<configuration>
     <system.web>
       <compilation debug="true"
         assemblyPostProcessorType="PostSharp.AspNet.AssemblyPostProcessor, PostSharp.AspNet"/>
     </system.web>
</configuration>

Additionally, you have to add the <postsharp … /> section in the configuration file:

<?xml version="1.0"?>
<configuration>
 <!-- Add a configuration handler for PostSharp. -->
 <configSections>
  <section name="postsharp"
                         type="PostSharp.AspNet.Configuration.PostSharpConfiguration, PostSharp.AspNet"/>
 </configSections>
 <!-- PostSharp configuration -->
 <postsharp directory="P:\open\branches\1.0\Core\PostSharp.MSBuild\bin\Debug" trace="true">
  <parameters>
   <!--<add name="parameter-name" value="parameter-value"/>-->
  </parameters>
  <searchPath>
   <!-- Always add the binary folder to the search path. -->
   <add name="bin" value="~\bin"/>
   <!-- Then add the location of plug-ins that are not installed in standard locations. -->
   <add name="laos-weaver" value="P:\open\branches\1.0\Laos\PostSharp.Laos.Weaver\bin\Debug"/>
  </searchPath>
 </postsharp>
 <appSettings/>
 <connectionStrings/>
 <system.web>
  <!-- Note the 'assemblyPostProcessorType' attribute. -->
  <compilation debug="true"
                             assemblyPostProcessorType="PostSharp.AspNet.AssemblyPostProcessor, PostSharp.AspNet">
  <authentication mode="None"/>
  <trace enabled="true" pageOutput="true"/>
 </system.web>
</configuration>
 

In all configuration parameters and in search path elements, the tilde character (~) is replaced by the physical path of the application.

Be prepared that the compilation will be much much longer, especially if it is fine-grained…

This is a preliminary version, feedback is welcome!

Happy postsharping!

Gael

PostSharp4Unity modifies assemblies after compilation to make objects
self-configurable: you don’t need to call a factory method; you can use the
default constructor. All you have to do is to decorate your class with the
custom attribute “Configurable”. It smells like Spring, isn’t it ;-).

It is available from

http://code.google.com/p/postsharp-user-plugins/.

I have updated the StopLight sample. The first change is on the
StoplightForm class:

[Configurable]
public partial class StoplightForm : Form, IStoplightView
  {

Then, in Program.Main, you can use the default constructor:

Application.Run(new StoplightForm());

Unfortunately, that’s not all. Since Unity has no notion of context registry
(i.e. no notion of “current container”), you have to build a basic one:

public sealed class UnityContainerProvider : IUnityContainerProvider
{
   private readonly IUnityContainer container;

    public UnityContainerProvider()
    {
       this.container = new UnityContainer()
         .Register<ILogger, TraceLogger>()
         .Register<IStoplightTimer, RealTimeTimer>();
    }

    public IUnityContainer  CurrentContainer
     { get { return this.container; } }
}  

Then tell
PostSharp4Unity to build your container:

[assembly: DefaultUnityContainerProvider(
  typeof(UnityContainerProvider))]

As you can see, there is a little of set up to do, but it’s only once per
assembly. (And would be useless if there were some Unity-wide notion of
context registry or default container.) At this price, you can use Unity
with any object without having to construct them using a factory method.

Pay attention that your
‘configurable’ objects are now configured before the constructor is
executed, and not after. So, in the class StoplightForm, we have to
move the view initialization at the end of the constructor:

[Configurable]
public partial class StoplightForm : Form, IStoplightView
{
   private StoplightPresenter presenter;

   public StoplightForm()
   {
      InitializeComponent();
      presenter.SetView(this);
    }

   [Dependency]
    public StoplightPresenter Presenter
    {
      get { return presenter; }
      set { presenter = value; }
    }

There are still some problems being discussed, but at least you have the
first bits.

Happy PostSharping!

Gael

I have been quite laconic in the release announcement about relicensing. Much
more was said on the licensing
page, but yet I got some feedback that it was not clear.

The summary of PostSharp licensing is: Runtime libraries are released
under the non-viral LGPL license; compile-time components are released under
GPL.

The first thing to realize is that
chances are great that
relicensing changes nothing to your life. Indeed, programs that
are transformed by PostSharp are not contaminated by GPL,
since they reference only runtime libraries of PostSharp. Basically, if your
program does not need the library PostSharp.Core.dll to be present on
your customer's computer, using PostSharp does not affect your program's
licensing scheme at all. And I'm pretty sure it's the case of 99% of users.

So who is impacted by the GPL license? Well, people who develop programs that
use PostSharp to modify other assemblies. In other words: if your program
transform the programs of your customers, read on.

Anyway, what kind of programs modify other programs? There are two typical
families of products that fall in that category: O-R mappers, obfuscators,
optimizers, code generators are the first one; they are typically deployed only
on development machines. Another family includes application servers offering
aspect-oriented services (AFAIK there is none for .NET, but in the Java
world it's quite common for an application server to have an integrated AOP
engine). Of course a special member of that family is the still-unreleased
Starcounter object database server; deploying .NET assemblies to this server
will make classes "magically" persistent in a server environment.

What if your program uses core parts of PostSharp? Actually, you are not
automatically infected by GPL. You have the following options:

• If you don't distribute your work outside of your company, you are not
  infected. So if you make an in-house plug-in, you are okay.
• You can release your work under any license approved by the
  Open Source Initiative. Well,
  attention: all your work, and not only the assembly directly referencing
  PostSharp.
• You can acquire a commercial license, which is basically a GPL exemption
  for your products. Exemptions will be provided on an individual, per-product
  basis. Since the number of customer of these licenses is quite small,
  exemptions will be given as a part of a partnership program including
  support and NDA. The idea there is to have a few good customers with a
  strong relationship. The "masses" have the product for free (anyway with a
  level of support often quoted as better than commercial one).

An important point is that the licensing itself is in 'candidate'
phase. If it makes you feel badly, do not hesitate to react. The point
is that, given the size and the complexity of the product, it is not possible
any more to develop and support it exclusively during free time, so I must raise
some money. I would like the product to be supported by few key partners having
a strong interest in PostSharp, and let it free for most (99%) people.

Happy PostSharping!

Gael

An interesting post on The Simple Part explains how to use PostSharp to implement an “Undo” feature in Jasema, a tool to create WPF Path Geometry in an easy user friendly way.

The trick is to apply a “journaling” aspect on some front-end methods. The aspect record the object state before and after execution.

Congratulations to ‘Karlagius’ for this original use of AOP!

Gael

Ruurd Boeke has recently released
PostSharp4ET, a PostSharp plug-in allowing to use Microsoft Entity Framework
without plumbing code — PostSharp generates it for you at build-time.
PostSharp4ET is released as a part of
Entity Framework Contrib hosted
on CodePlex.com.

With PostSharp4ET, enabling persistency on a class should be as easy as
decorating it with a custom attribute:

[Poco("ConnectionName")]
public class Person
{
   public int PersonID { get; set; }
   public string Firstname { get; set; }
   public string Lastname { get; set; }
}

Under the hood, EF-specific interfaces are implemented automatically at build
time.

Ruurd

explains everything extensively on his blog. And even if you are not
interested in Microsoft Entity Framework, Ruurd's blog is a great introduction
to how to write more complex aspect libraries with PostSharp.

Thank you Ruurd for this excellent work!

I am pleased to announce the long awaited second release
candidate of PostSharp 1.0 available for download.

This is a stability release solving all bugs discovered in the
previous release, which has been downloaded over 6 thousand times.

Additionally to 40 bug fixes, this release brings important changes in licensing and minor
improvement in the installer and packaging.

Relicensing

With this release (and from revision 287 exactly), the whole
PostSharp code base has been relicensed from GPL/LGPL/MPL to a GPL 3 / LGPL 3
scheme. Don’t be afraid: this relicensing actually affects only a few of you.
Run-time components are licensed under LGPL, compile-time components
under GPL. So it is still free to use PostSharp and PostSharp Laos in
your applications, but if you distribute an application that uses PostSharp to
transform assemblies (like an O-R mapper), and don’t want to release your work
as open-source, then you are kindly requested to acquire a commercial license.

This licensing scheme is really directed to have
ISV making money on PostSharp contributing to the project.
Commercial licenses will be available to “a selected few” under
a partnership program.

Don’t be afraid: I have no plan to “lock”
end-users in GPL licenses.

You will find more about licensing on the website. If you
have any question, or if you think you will need a commercial license, do not
hesitate to contact me.

Improved Distribution Packages

A minor improvement of the MSI package is that you can now
choose not to install PostSharp in the GAC. PostSharp actually does not
need to be in GAC; I put there to benefit from NGen. If you want to disable GAC
installation and NGeneration, choose the custom installation mode and disable
the option.

Another improvement is that I now provide a package for
xcopy deployment as well as instructions describing how to insert PostSharp
in the MSBuild process at global or project level.

What’s next?

I’m sometimes asked for a roadmap with dates…
and when I give some I suddenly get in the incapacity to respect
them! I acknowledge it took me to long to deliver this release.
The reason is that I had to work on another project and I had to
invest the remaining time in the website migration, which became
really urgent. Now that the website is up and that I will have
some time dedicated to the project (I will blog about it soon),
things should go more smoothly. The idea is to deliver a release
candidate every month and to declare the 1.0 branch as stable as
soon as the number of reported bugs become acceptable. It’s
difficult to predict how many iterations it will take, but I
still hope to have the stable release for Q2 of this year.

Happy aspecting and keep on good work reporting
bugs!

Gael

It has not happened before publishing the first release candidate in October: PostSharp has reached a zero-bug point again. This means that it is ready for a new release candidate.

May I kindly ask all who have reported a bug (and all who have some minutes to loose) to download the latest build from http://download.postsharp.org/builds/1.0. If everything is ok I will publish the RC2 next week.

Thank you!

Gael

I am proud to announce that PostSharp will be presented at AOSD 2008, the most important conference of the Aspect-Oriented community.

The paper is called User-friendly aspects with compile-time semantics in .NET and insists on original contributions of PostSharp Laos to the art of aspect-oriented development.

I will present my work in Brussels on Wednesday, April 2th, 2008 and will attend the conference from Tuesday to Friday of this week.

If anyone if interested in meeting me in Brussels, just let me know. If many are interested, we could organize a workshop on the side of the conference. Just leave a comment to this blog.

Happy aspecting!

Gael