大家可能已经知道.net 2.0将会集成一个build tool:msbuild，当然，大家也知道，这明显的同.net社区中的nant功能重合。在此事上，我个人极度反感微软的做法。让我们来看看，如果java没有apache软件基金会的一些项目，java会像有这样的影响力？ 微软真正的做法应该像sun将servlet和jsp引擎源代码捐赠给apache软件基金组织或是像ibm捐赠eclipse一样。让nant开发团队来做msbuild。毕竟，.net的发展很大程度上决定于.net社区的活跃层度。

关于msbuild的细节，我们可以从pdc 的session中了解 下载该ppt
随该ppt提供的sample带有一些文档，对msbuild进行了较为详细的介绍，这可能是当前惟一的msbuild的介绍资料了

无论是msbuild或是nant,都非常简单易用，msbuild除了build新格式的项目文件外，还能编译vs 2003的项目文件。从功能上来说nant现在要丰富一些，但msbuild将来绝不会逊色于nant,未来，估计nant只会在mono项目中拥有一席之地，我替nant感到难过:(

msbuild和nant均使用xml格式保存项目文件，从总体上语义类似，如根元素project,主要的tag: target等，但从文件格式上两者是不兼容的，下面说明以下主要的结构上的区别，方便大家同时掌握此两者。

元素命名
msbuild 使用Pascal命名法，nant使用纯小写

属性(property)

1、声明
nant:
<property name="propertyname" value="propertyvalue"/>

msbuild
<Property propertyname="propertyvalue"/>
2、使用
nant:
${propertyname}
msbuild
$(propertyname)

msbuild还有(PropertyGroup)属性组的概念

任务(task)
nant和msbuild的task模式不同，nant是每个任务一个标记，如
<csc output="hello.exe" target="exe">
....
</csc>

而msbuild则只有一个标记task，通过name属性来进行区别
<Task Name="CSC">
....
</Task>
同nant类似，msbuild允许你通过继承Task来创建自己的Task

FileSet vs Item
nant使用FileSet的概念，比方说，以下说明需要编译的文件，其中references,sources就是FileSet
<project name="testmsbuild" default="Build">
<target name="Build">
<csc target="exe" output="test.exe">
 <references>
  <includes name="bin\mydll.dll"/>
  <include name="bin\mydll2.dll"/>
 </references>
 <sources>
  <includes name="test.cs"/>
  <includes name="person.cs"/>
 </sources>
</csc>
</target>
</project>
msbuild使用Item的概念，用type属性来区别，允许多个同type的Item，如果使用@(typename)引用则成为ITaskItem Array，像Soruces,References 都接受ITaskItem Array（string array 是通过;分隔来实现的)
<Project  DefaultTargets="Build">
 <Item Type="CSFile" Include="msbuild.cs"/>
 <Item Type="Reference" Include="Person.dll"/>
 <Target Name="Build">
  <Task Name="CSC" Sources="@(CSFile)"  OutputAssembly="testmsbuild.exe" TargetType="exe" References="@(Reference)"/>
 </Target>
</Project>

个人看法

就我自己而言，我还是喜欢nant,当然，主要是msbuild当前仅提供有限的功能。而nant，似乎已经到了无所不能的境界，大家用用便知。