Archive

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

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