February 16, 2004

MSBuild = Ant?

Back in October, 2003 Steve Loughran had posted his first-glance thoughts on MSBuild. Although mostly critical, he has made some very valid points and observations. It looks like this new tool is a bit more limiting than Ant or Nant. Microsoft has done nothing illegal (or have they?) being that Ant is open source, but where does that put the Ant/Nant development community?

[0] This is where you will find the docs on MSBuild from the PDC.

Posted by 0xFF3300 at 01:06 PM | Comments (2) | TrackBack

February 04, 2004

Build.Net: Getting it Together

It's been a long time coming, as I've decided to get my release together for Build.Net. This all started when I began using Nant, mainly the SolutionTask and found that the task barely works for large heterogenous builds. Previous to Nant, I had used make, nmake, various home-grown batch files and the awesome Ant. So I decided to create my own build tool; nothing fancy, just something that can take a list or directory of Visual Studio project files and create an automated build. Where my tool differs greatly form the SolutionTask is that is treats each independent .*proj file as it's own build, and emits and dependent binaries that are needed for the build, then it creates a nice little csc command line and outputs the appropriate binary. Since I do like Nant auotmating things (just not building) I have also made a Nant task to support it's use.

Posted by 0xFF3300 at 10:33 PM | Comments (2) | TrackBack

January 12, 2004

NAnt Project Overrides

After reading message about project reference overriding: Re: [nant-dev] solution task addin and the documentation on SolutionTask, I am wondering if Nant Project Overrides were ever implemented, it's certainly a good idea. But upon reading the SolutionTask entry, there seems to be no such documentation. :(

"The SolutionTask allows you to build your projects in batches and use previously-built projects as part of your current build, using the reference configuration matching. As an example, we will examine a build file for a company that builds a set of core DLLs (projects-1.txt), followed by a set of other DLLs or applications (projects-2.txt). These files may be built in seperate NAnt build files, but for simplicity, we will place them in the same file."

Posted by 0xFF3300 at 08:17 AM | Comments (1) | TrackBack

December 24, 2003

NAnt, Why?

After using NAnt for sometime, it fairly well designed build tool, especially since it's inspiration came from Ant.

I have used Apache Ant extensively and cannot think a better build tool for build/develop of Java projects. So when I saw NAnt, I thought that this should be a great tool for building .NET projects. And it is, but my problem is that since most .NET developement is IDE based (please correct me if I am wrong, especially using VS.NET, see NOTE), you already are provided with a 'build' file of sorts as the csproj, etc. NAnt does come with SLiNgshoT.exe, a tool that converts solution files to NAnt build files and/or NMake files. I truly believe that NAnt's real value comes being able to exceute the associated unit tests with a build and build related documentation. Now Nant is good up until the point that you are using VS solution files. Essentially my build script consists of 60+ solution files. It looks like this:


<target name="build" description="compiles the source code"<
<echo message="Base Build Directory = ${nant.project.basedir}"/>
<echo message="Logging Directory = ${log.dir}"/>
<tstamp property="build.date" pattern="yyyyMMdd" verbose="true"/>
<!--
Full Ordered Build, Take From Build Log.
This Should Be Built Dynamically.
-->
<solution configuration="${build.type}" solutionfile="${src.dir}\Flood\NET.Flood.FloodLib\NET.Flood.FloodLib.sln"/>
<solution configuration="${build.type}" solutionfile="${src.dir}\3rdParty\log4net\src\log4net.sln"/>
<solution configuration="${build.type}" solutionfile="${src.dir}\NET.Data\NET.Data.sln"/>
<solution configuration="${build.type}" solutionfile="${src.dir}\NET.Inquiry\NET.Inquiry.sln"/>
<!-- 70 more solution file entries down here... -->
</target>

As you see above, my NAnt build file is extremely straightforward. I have accomplished the same running a batch script that executes devenv.exe with the appropriate solution file. Also notice that I have orded the solution files in order of dependency.

What I need here is a tool to recursively search my project main source tree, scan all solution files and based on dependency create the FULL build script.

Build Tool Requirements:

  • List Builder. Recursive directory search for *.csproj or *.sln files to create the List OR pass the List of files to build.
  • Derive the Master Build List (MBL). Basically take a List of projects to be built and create the Master Build List based solely on non-System dependencies.
  • Build from the Master Build List. Emit all the binaries from the MBL using Override options.
  • Overridable Options. Allow the user to Override Project Output Directory, Override Debug Settings.
  • Log Output. Log all build output consistently using logging framework.
  • Optional: Multi-Threaded compilation. Compile projects without dependencies upon each other inside their own Thread.

    Note About IDEs: For any of my shared open source projects I have been using the Sharpdevelop IDE. Prevoius incantations have been shaky and a little slow, but the latest version runs very well and is much faster (and it's free).

    To Be Continued.

    Posted by 0xFF3300 at 09:11 AM | Comments (4)