Mike Nichols - Son Of Nun Technology

Syndication

Images in this post missing? We recently lost them in a site migration. We're working to restore these as you read this. Should you need an image in an emergency, please contact us at imagehelp@codebetter.com
Considerations For Using PostSharp

I recently started using PostSharp for implementing AOP into my current project. It's a great project and really simplifies some specifications we have that could have been cumbersome. Introducing this into an environment that is using NAnt and development using TDD took some exploration for me so I thought I'd log some things I had to overcome.

Building from NAnt

I saw that there was an NAnt task created for PostSharp but I either couldn't get it going, or I couldn't find it ( I can't remember). I ended up just using the command line app included with PostSharp, so I have an NAnt target that invokes the utility from within my project default.build file:

<target name="postsharp">

<copy file="${build.dir}/${project::get-name()}.dll" tofile="${build.dir}/Pre.${project::get-name()}.dll" overwrite="true"/>
<
exec program="${build.dir}/PostSharp.exe"> <arg value="${build.dir}/Default.psproj" />
<
arg value="${build.dir}/Pre.${project::get-name()}.dll" />
<
arg value="/P:Output=${build.dir}/Post.${project::get-name()}.dll" />
<
arg value="/P:ReferenceDirectory=${build.dir}" /> < arg value="/P:SearchPath=${build.dir}" />
<
arg value="/P:IntermediateDirectory=${build.dir}" /> < arg value="/P:CleanIntermediate=False" /> < arg value="/P:MSBuildProjectFullPath=D:\path\to\src\app\Cei.MaterialsTesting\${project::get-name()}.csproj" />
<
arg value="/P:SignAssembly=True" />
<
arg value="/P:PrivateKeyLocation=${root.dir}/my.snk" /> </ exec> A few things to note here. I had to first make a copy of the assembly I am manipulating and rename it with an 'Pre.assemblyname' prefix (or whatever). The dll was getting locked during the build so PostSharp would complain. The output of PostSharp is 'Post.<assemblyname>' and then I copy that after the utility runs. I think I had the same locking issue that forced me to do this. Notice I am doing everything in my build directory so I had previously copied over all required PostSharp files to do that when I copy all other dependencies: <copy todir="${build.dir}" >

<fileset basedir="\${tools.dir}/PostSharp">

<include name="*.dll" />
<
include name="*.exe" />
<
include name="*.targets" />
<
include name="*.psproj" />
<
include name="*.config" />
<
include name="*.psplugin" />
<
include name="*.version" />
</
fileset>

</copy>

TDD Becomes Heavy

The compilation times are considerably larger due to the post-compilation magic. When you are used to almost instant feedback in the IDE this starts out as being an irritation then begins to affect how I write my tests - not good. I will probably pull my aspect related tests into their own test assembly and then target assemblies that are actually used in the app will require some kind of environment condition on the PostSharp targets setup in the .csproj files. I haven't resolved the better approach to take to get around this.  I know my own tendency toward impatience will cause me to write bad tests, or not at all, if I have to wait for each rebuild to take so long so I need to keep it quick.

Posted 11-23-2008 11:19 PM by Michael Nichols
Filed under: ,

Gael Fraiteur wrote re: Considerations For Using PostSharp
on 11-24-2008 7:18 AM

Michael,

Much of the build-time performance burden comes from loading all the assemblies into the CLR. If you use the command line, be sure to generate native images (ngen).

Apart from that little trick, I ack that post-compilation may be a pain for TDD.

-gael

Dew Drop - November 24, 2008 | Alvin Ashcraft's Morning Dew wrote Dew Drop - November 24, 2008 | Alvin Ashcraft's Morning Dew
on 11-24-2008 8:10 AM

Pingback from  Dew Drop - November 24, 2008 | Alvin Ashcraft's Morning Dew

CodeBetter.Com FAQ

Our Mission