我正在使用MSBuild来构建我的东西。我想将Build Server用作CruiseControl.net。

现在，CCNET经常引用nAnt，但看起来ccnet可以完成nant通过项目配置和msbuild可以完成的大部分工作。此外，nAnt似乎还不受支持，它的Beta版本已经将近一年了。

简而言之：我实际上对MSBuild非常满意(特别是因为它是"官方"编译器前端)，而对nAnt则不太满意，但是我不想过早地做出判断。

在MSBuild上使用nAnt的原因是什么？尤其是对于ccnet，在功能上似乎与nant有点重叠(并添加了与自动构建相关的内容)

解决方案

回答

我认为这更多是个人喜好问题。 nAnt是一个很好的框架，而MSBuild几乎具有同样的功能。借助轻松开发自定义任务的能力(在两个框架中)，我们可以完成几乎所有需要做的事情。

我无法回答我们问题的"仍受支持"部分，但是我想说，如果我们已经对nAnt感到满意，那么它可能是可行的。如果我们(或者小组中的某人)熟悉MSBuild，那么这也是一种不错的选择。

回答

老实说，这取决于哪种方式更适合环境。如果我们使用许多非Microsoft工具，请使用nunit，ccnet，ncover。我们可能会在nant身上找到更好的支持。或者，如果我们使用的是MSTest，TFSBuild，则可能会发现MSBuild更好的环境。我会两者兼而有之，并且使用每种方法都更适合环境。

回答

如果我们已经使用nAnt进行了一堆自定义任务，那么坚持下去，使用MSBuild并不会带来太多好处。就是说，似乎没有任何事情可以让nAnt做到MSBuild不能做到的核心。两者都可以调用外部工具，都可以运行基于.Net的自定义任务，并且都具有大量社区任务。

出于同样的原因，我们在这里使用MSBuild，因为它现在是VS的默认构建系统，并且我们没有任何nAnt特定的问题要担心。

MSBuildCommunityTasks是一个很好的第三方任务库，它涵盖了我在nAnt中所做的大多数自定义内容，包括VSS和Subversion支持。

回答

如果我们对MSBuild非常满意，那么我会坚持使用MSBuild。这可能是我们最喜欢的工具是我们最喜欢的一种。我从NAnt开始，不能完全适应MSBuild。我敢肯定他们俩都将待一段时间。

两者之间存在一些根本差异，可能是一些NAnt粉丝与Microsoftie之间的对话最能突出这一点。

有趣的是，杰里米·米勒(Jeremy Miller)去年在他的博客上提出了完全相反的问题。

回答

CC.NET只是构建服务器技术，而不是构建脚本技术。我们在工作中使用CC.NET可以非常成功地成功调用MSBuild构建脚本。

NAnt是一种较旧且更成熟的构建脚本语言，但是它们的工作方式相似。我在NAnt中几乎没有什么可以在MSBuild中完成的，因此实际上取决于我们更喜欢哪一种。就NAnt的活跃程度而言，不要错过最后一个发行版的时间……而要等到最后一个夜间构建的时间。 NAnt往往在发布之间间隔很长时间，但是夜间版本通常相当稳定。

回答

就像许多人已经指出的那样，这里的答案是"取决于"。在NAnt中，有一些诸如重复操作之类的事情变得更加简单和简洁。有关此问题，请参见MSDN论坛。

回答

我发现我们也可以使用混合方法，尤其是在大型项目中。开发新组件时，我们的许多nant脚本都将转换为msbuild。两者都支持相同的主要功能，并且如果我们找到一个本机支持的任务，而另一个却不支持，则可以相互调用。

从MSBuild开始的新.NET开发可以节省大量时间，因为它可以直接运行解决方案文件。从主编译中扩展以执行其他任务(源代码控制，部署等)效果很好。