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