C# – Why would I want to continue to use Nant when MSBuild is available

Yes, it is important if your item will be used as a key in a dictionary, or HashSet<T>, etc - since this is used (in the absence of a custom IEqualityComparer<T>) to group items into buckets. If the hash-code for two items does not match, they may never be considered equal (Equals will simply never be called).

The GetHashCode() method should reflect the Equals logic; the rules are:

• if two things are equal (Equals(...) == true) then they must return the same value for GetHashCode()
• if the GetHashCode() is equal, it is not necessary for them to be the same; this is a collision, and Equals will be called to see if it is a real equality or not.

In this case, it looks like "return FooId;" is a suitable GetHashCode() implementation. If you are testing multiple properties, it is common to combine them using code like below, to reduce diagonal collisions (i.e. so that new Foo(3,5) has a different hash-code to new Foo(5,3)):

unchecked // only needed if you're compiling with arithmetic checks enabled
{ // (the default compiler behaviour is *disabled*, so most folks won't need this)
    int hash = 13;
    hash = (hash * 7) + field1.GetHashCode();
    hash = (hash * 7) + field2.GetHashCode();
    ...
    return hash;
}

Oh - for convenience, you might also consider providing == and != operators when overriding Equals and GetHashCode.

A demonstration of what happens when you get this wrong is here.

I've done a similar investigation this week. Here's what I've been able to determine:

NAnt:

• Cross-platform (supports Linux/Mono). It may be handy for installing a web site to multiple targets (that is, Linux Apache and Windows IIS), for example.
• 95% similar in syntax to Ant (easy for current Ant users or Java builders to pick up)
• Integration with NUnit for running unit tests as part of the build, and with NDoc for producting documentation.

MSBuild:

• Built-in to .NET.
• Integrated with Visual Studio
• Easy to get started with MSBuild in Visual Studio - it's all behind the scenes. If you want to get deeper, you can hand edit the files.

Subjective Differences: (YMMV)

• NAnt documentation is a little more straightforward. For example, the MSBuild Task Reference lists "Csc Task - Describes the Csc task and its parameters. " (thanks for the "help"?), vs the NAnt Task Reference "csc - Compiles C# programs." UPDATE: I've noticed the MSBuild documentation has been improved and is much better now (probably on par with NAnt).
• Not easy to figure out how to edit the build script source (*.*proj file) directly from within Visual Studio. With NAnt I just have Visual Studio treat the .build script as an XML file.
• Apparently, in Visual Studio, Web Application Projects don't get a *.*proj file by default, so I had great difficulty figuring out how to even get MSBuild to run on mine to create a deployment script.
• NAnt is not built-in to Visual Studio and has to be added, either with an Add-In, or as an "External Tool". This is a bit of a pain to set up.
• (Edit:) One of my coworkers brought this up--if you want to set up a build machine using CruiseControl for continuous integration, CruiseControl integrates with NAnt nicely out of the box. UPDATE: CruiseControl also has an MSBuild task.
• Please see comments below for full and up-to-date discussion of subjective differences.