我正在使用 MSBuild 来构建我的东西。我想通过 Build Server 使用 CruiseControl.net。
现在，CCNET 经常引用 nAnt，但看起来 ccnet 似乎可以完成 nant 通过项目配置和 msbuild 可以完成的大部分工作。此外，nAnt 似乎有点不受支持，现在已经有将近一年的 Beta 版本。
简而言之：我实际上对 MSBuild 很满意（特别是因为它是“官方”编译器前端），对 nAnt 有点不舒服，但我不想过早判断。
在 MSBuild 上使用 nAnt 的原因是什么？尤其是 ccnet，它在功能方面似乎与 nant 有一些重叠（并添加了与自动构建相关的东西）
如果您对 MSBuild 非常满意，那么我会坚持使用 MSBuild。这可能是您首先学习的工具是您更喜欢的工具的情况之一。我从 NAnt 开始，不太习惯 MSBuild。我敢肯定他们都会在相当长的一段时间内出现。
两者之间存在一些根本差异，一些 NAnt 粉丝和 Microsoftie 之间的对话可能最能突出显示。
有趣的是，Jeremy Miller去年 在他的博客上提出了完全相反的问题。
在我看来，这更多是个人喜好的问题。nAnt 是一个很棒的框架，MSBuild 几乎同样强大。凭借轻松开发自定义任务（在两个框架中）的能力，您几乎可以完成任何您需要做的事情。
我无法回答您问题的“仍受支持”部分，但我会说如果您已经对 nAnt 感到满意，那么它可能是可行的。如果您（或您小组中的某个人）熟悉 MSBuild，那么这也是一个不错的选择。
如果您已经有一堆与 nAnt 一起使用的自定义任务，请坚持使用它——您不会从 MSBuild 获得太多收益。也就是说，nAnt 似乎没有什么可以做，而 MSBuild 不能在其核心。两者都可以调用外部工具，都可以运行基于 .Net 的自定义任务，并且都有大量的社区任务。
我们在这里使用 MSBuild 的原因与您相同 - 它现在是 VS 的默认构建系统，我们无需担心任何特定于 nAnt 的东西。
MSBuildCommunityTasks是一个很好的第三方任务库，它涵盖了我在 nAnt 中做过的大部分自定义内容，包括 VSS 和 Subversion 支持。
CC.NET 只是构建服务器技术，而不是构建脚本技术。我们在工作中使用 CC.NET 非常成功地调用 MSBuild 构建脚本，没有任何问题。
NAnt 是一种较老且更成熟的构建脚本语言，但它们的工作方式相似。我在 NAnt 中可以做的事情很少，而在 MSBuild 中我也做不到，所以这真的归结为你更喜欢哪一个。就 NAnt 的活跃程度而言，不要以最后一次发布的时间为准……而是以最后一次夜间构建的时间为准。NAnt 在发布之间往往会持续很长时间，但每晚构建通常非常稳定。
老实说，这取决于什么更适合您的环境。如果你使用很多非微软工具，nunit、ccnet、ncover。您可能会在 nant 中找到更好的支持。或者，如果您使用 MSTest、TFSBuild，您可能会发现 MSBuild 是一个更好的环境。我会同时学习并使用哪个更适合您的环境。
就像很多人已经指出的那样，这里的答案是“视情况而定”。在 NAnt中有一些类似重复操作的东西更简单、更清晰。有关此问题的讨论，请参阅MSDN 论坛。
我发现您也可以使用混合方法，尤其是在大型项目中。当开发新组件时，我们的许多 nant 脚本都被转换为 msbuild。两者都支持相同的主要功能，并且如果您发现其中一个本地支持但另一个不支持的任务，则可以相互调用。
对于从 MSBuild 开始的新 .NET 开发，可以为您节省大量时间，因为它可以直接运行解决方案文件。从主编译扩展以执行其他任务（源代码控制、部署等）效果很好。