I am happy to announce that I started this week a long-term partnership with Starcounter AB, a Stockholm-based software shop producing a next-generation object database management system (ODBMS) that will make you understand the benefits of 64-bit hardware. I am not allowed to give too much details, but I'll sure do it once it will go public. Believe me, it sounds cool!

The good thing for PostSharp is that the partnership plans to reserve 40% of regular working time to PostSharp development. To be more precise, I will work in the average 3 days a week for Starcounter, but at a rate that allows me to invest the rest of the time in PostSharp.

Starcounter is already a old partner of PostSharp. Contacts started in June 2006, when they started considering PostSharp in their product. In November 2006, they sponsored the development of the hosting infrastructure, which allows to host PostSharp easily in server environments. In May-July 2007, they hired me to implement PostSharp in their product. The money allowed me to pack and publish the first release candidate, which was a really great step!

PostSharp just took too more time to be done in spare time (do you realize the time it takes to support users, correct bugs, and promote the project?). I am happy that our agreement will guarantee the future of PostSharp.

A great new for the community expecting long-term project viability!

Happy PostSharping!

Gael

If you belong to those who don't like global installations, the latest release candidate should make you happy: there is now a binary distribution without installer.

This distribution should remove much of the mystery about how PostSharp integrates in the build process. Actually, since the installer does not modify the MSBuild target files for you, you have to do it yourself. The interesting thing is that you can do it in a per-project basis: instead of modifying global MSBuild target files, you can just import PostSharp in the projects that actually need it.

If you think this kind of installation is for you, download the 'Binary - No Installer' package, and read carefully the installation instructions in the file doc/Build-Instructions.html.

Since this kind of distribution is quite new, I am looking forward for your comments.

Happy PostSharping!

Gael

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