Liam McLennan

Using NAnt to build .NET 3.5 solutions

First, let me recommend Mike Robert's excellent article on setting up .NET solutions.

My preference is to use MSBuild to build the Visual Studio solutions, and NAnt for everything else. The trouble is, in the latest version of NAnt (0.86-beta1) the <solution> task does not support .NET 3.5.  The best work around I can find is to use the <exec> task to call MSBuild to build the solution. Here is a basic Nant build script that does this:

<?xml version="1.0" ?> 

<project name="nant" default="compile" xmlns="http://nant.sf.net/schemas/nant.xsd">      
	
	<property name="nant.settings.currentframework" value="net-3.5" />
	<property name="project.rootdirectory" value="." />
	<property name="solution.dir" value="src"/>     
	<property name="solution.file" value="${solution.dir}/Mysolutionfile.sln"/>     
	<property name="build.configuration" value="debug" />      
	
	<target name="compile">
		<exec program="${framework::get-framework-directory(framework::get-target-framework())}\msbuild.exe"         
			commandline="${solution.file} /t:Clean /p:Configuration=${build.configuration} /v:q" workingdir="." />     
	</target>      

</project>

The Silver Lining to the SOA Storm Cloud

For years I have been an SOA sceptic, and I remain so. As many have pointed out, SOA is an over-hyped and under-defined technology. Lately, however, I have detected a silver lining to the SOA storm cloud.

It began with an inkling as to why SOA is so popular with senior managers. "Could it be", I thought, "that they dislike ERP software as much as I do?" To borrow a term from Jeff Atwood, ERP is "crapware".

Might SOA be an alternative to ERP? Rather than monolithic crapware we could have many niche applications, each performing their one task with talent, precision and beauty. And rather than hire an army of overpriced consultants to customise an ERPsolution you would only need to hire a slightly smaller army of slightly less overpriced consultants to integrate the many niche applications into your SOA brave new world.

I still think SOA is mostly hype, but integration is something that I believe in. I hope in the future to see the integration of many specialised applications begin to replace the acceptance of mediocre ERP solutions.

Single Responsibility Principle

For those not familiar with the single responsibility principle here is a good description from the c2 wiki.

• Each responsibility should be a separate class, because each responsibility is an axis of change.
• A class should have one, and only one, reason to change.
• If a change to the business rules causes a class to change, then a change to the database schema, GUI, report format, or any other segment of the system should not force that class to change.

It is a counter-intuitive but valuable principle of object-oriented design. I came across this example today:

My application is using  a service layer between the UI and the domain model. On my ProductService I have a method that is used to add images to products. When an image is added it must be saved in three different sizes. The old me would have included the image resizing code in the ProductService, that is the intuitive thing to do.

Following the single responsibility principle I instead created an ImageResizingService class to handle the resizing. So now my ProductService is dependant upon ImageResizingService (or at least its interface) but it has no knowledge of how to resize an image, and my Image class remains gloriously dependency free.