我应该从 nant 切换到 msbuild 吗？

Posted 2023-03-30

【中文标题】我应该从 nant 切换到 msbuild 吗？

【英文标题】：Should I switch from nant to msbuild?

【发布时间】：2010-09-05 20:30:41

【问题描述】：

我目前使用 nant、ccnet（巡航控制）、svn、mbunit。我使用 msbuild 来构建我的 sln 只是因为它更容易脱壳。

将我的整个构建脚本切换到 MSBuild 有什么好处吗？我需要能够运行测试、watir 风格测试、xcopy 部署。这更容易吗？

更新：是否有任何引人注目的功能会导致我从 nant 转向 msbuild？

【问题讨论】：

***.com/questions/476163/…

webwesen 在这个宇宙中发现了一个递归漏洞，引用了一个不存在的问题，不应该是另一种方式吗？

【参考方案1】：

我喜欢 MSBuild。一个原因是 .csproj 文件是 msbuild 文件，在 VS 中构建就像在命令行中构建一样。另一个原因是我一直在使用的 CI 服务器 TeamCity 的良好支持。如果您开始使用 MSBuild，并且想要在构建过程中执行更多自定义操作，请获取 MSBuild Community Tasks。他们给你一堆不错的额外任务。我已经好几年没用过 NAnt 了，我也没有后悔过。

此外，正如 Ruben 提到的，CodePlex 上有 SDC Tasks 任务。

为了更有趣，还有MSBuild Extension Pack on CodePlex，其中包括一个推特任务。

【讨论】：

还有 SDC 任务。还有哈希米书。

【参考方案2】：

我的建议正好相反——避免 MSBuild 就像瘟疫一样。 NANT 更容易设置您的构建以进行自动测试、部署到多个生产环境、与 Cruisecontrol 集成以实现入门环境、与源代码控制集成。我们在使用 TFS/MSBuild（使用 TFSDeployer、自定义 powershell 脚本等）方面经历了很多痛苦，以使其能够完成我们使用 NANT 开箱即可完成的工作。不要浪费你的时间。

【讨论】：

+1 MSBuild 有它的位置，但 NAnt 更强大。我发现没有令人信服的理由进行切换，尤其是当 NAntContrib 中存在 任务时。

我已经广泛使用了这两者，虽然我不喜欢微软基本上复制 NAnt 的方式，但 MSBuild 更容易为其开发自定义任务，如果你将 MSBuild 社区任务与 MSBuild 扩展包结合起来，那么你有一个巨大的一系列工具。 MSBuild 之所以获胜，是因为它已集成到 MS 项目中。

Si，你错了。 1) NANT 中的 CustomTasks 尽可能简单 - 任务的子类 2) NANT 具有 NANTContrib 以及比 MSBuild 更多的社区支持 3) 我将 NANT 集成到我的 MS 项目中，编写一个批处理文件来运行 NANT.exe。这是一个构建，而不是火箭手术。

MSBuild 有所不同，但它与 Nant 一样易于使用且功能强大，尤其是使用扩展包。了解为您的 csproj 文件提供支持的工具也很有用。您可以深入了解构建对所有开发人员的操作方式（通过更改 csproj）并在每个构建中发生。它也少了一件需要安装的东西，此时 nant 似乎已经死了。

【参考方案3】：

使用 MSBuild 最令人信服的理由（至少在 .NET 3.5 及更高版本中） - 构建引擎可以同时构建。

这意味着在您拥有多个内核/处理器的情况下，您的构建速度会大大加快。

在 3.5 之前，MSBuild 不进行并行构建。

【参考方案4】：

我觉得 MSBuild 和 Nant 相当可比。如果您使用其中之一，我通常不会在它们之间切换，除非您选择的产品中缺少引人注目的功能。

我个人将 MSBuild 用于任何新项目，但您的使用范围可能会有所不同。

希望有帮助！

编辑： @ChanChan - @Jon 提到 Nant 不构建 .NET 3.5 应用程序。这可能足以成为改变或至少并行使用它们的理由。随着我越来越倾向于 MSBuild，我可能不是最有见识的人来强调这两种技术的任何其他展示者。

编辑：看起来 Nant 现在正在构建 .NET 3.5 应用程序。

【讨论】：

NANT 现在确实构建了 .net 3.5 应用程序。

【参考方案5】：

NAnt 存在的时间更长，是一款相当成熟的产品，而且 IMO 也更易于使用。如果您对构建可以在 Mono 以及 .NET 和 Silverlight 下运行的应用程序感兴趣，可以利用很多社区知识，而且它也是跨平台的。开箱即用，它比 MSBuild 所做的要多得多。哦，是的，您可以从 NAnt（好的，从 NAntContrib）调用 MSBuild :-)

不利的一面是，NAnt 及其姊妹项目 NAntContrib 似乎确实停滞不前，最近一次更新是在 2007 年底。

我看到的 MSBuild 的主要优点是它附带 .NET Framework，因此安装的产品少了一个；并且正在进行更积极的开发（尽管在某些地方可以赶上旧的 NAnt）。

就我个人而言，我发现它的语法有点难学，但我相信继续接触 ti 会让事情变得更容易。

结论？如果您正在使用现有的 NAnt 脚本，请坚持使用它们，不值得麻烦移植。如果您正在开始一个新项目，并且喜欢冒险，那就试试 MSBuild。

【参考方案6】：

我们也从 nant 切换到 msbuild。如果您的构建非常标准，那么设置它不会有太多问题，但是如果您有很多特定的构建任务，您将不得不编写自定义 ms 构建任务，因为 msbuild 的自定义任务要少得多。

如果您想显示合理的构建结果，您将不得不使用自定义记录器等。整个团队构建不如 nant 成熟。

但真正的好处是与 TFS 源代码控制和报告服务的集成。如果您不使用 TFS 作为您的源代码控制系统，那是不值得的。

【参考方案7】：

除非您有非常令人信服的理由（至少），否则不要切换。 NAnt 是开源的，如果不是，我将无法自定义我们的构建系统，MSBuild 不是。 NAnt 可以轻松运行 MSBuild，我不确定反过来。 如果您使用 VS2005 或更新版本，则已经为您编写了 MSBuild 脚本（项目文件

是

MSBuild 文件。） 如果您使用 NAnt，并且使用 VS 编辑项目文件、设置和配置，则必须编写一个转换器/同步工具来从 VS 项目文件更新您的 NAnt 文件。

【参考方案8】：

@布拉德·里奇

除非缺少一个引人注目的功能，否则我通常不会在它们之间切换

使用 msbuild 的令人信服的理由是什么？有缺点吗？

到目前为止，我从你的回答中得到了一个很好的“不，不要打扰”。

【参考方案9】：

我认为它们在功能和易用性方面都具有可比性。仅仅因为基于 C#，我发现 msbuild 比 nants 更容易使用，尽管这并不是一个令人信服的切换理由。

nant 到底没有为您做什么？或者您只是希望您可能会错过一些很酷的功能？ :)

关于 C# 的一个非常好的事情是，如果您拥有 .net 框架，那么您就拥有了运行 msbuild 所需的一切。当您在大型团队/项目中工作并且人员/硬件更替时，这非常棒。

就我个人而言，我更喜欢 SCons :)

【参考方案10】：

我仍然使用 nAnt 而不是 msbuild 进行自动构建的主要原因是我对构建有更精细的控制。由于使用 csproj 的 msbuild 有它的构建文件，因此该项目中的所有源代码都被编译到一个程序集中。这导致我的解决方案中有很多项目用于我分离逻辑的大型项目。有了 nant，我可以安排我的构建，我可以将我想要的东西从一个项目编译成多个程序集。

我喜欢这条路线，因为它使我不必在我的解决方案中使用许多项目文件。我可以有一个项目，其中包含文件夹拆分层，然后使用 nant 将每一层构建到它自己的程序集中。

但是，对于某些构建任务，例如构建 WPF 应用程序，我确实将 nant 和 msbuild 结合使用。在 nant 中使用 msbuild 目标编译 WPF 应用程序要容易得多。

为了结束这一点，我的回答是我喜欢并排使用它们，但是当我在此配置中使用 msbuild 时，它通常用于直接编译，而不是执行任何构建自动化任务，例如将文件复制到例如，生成帮助文档或运行我的单元测试。

【讨论】：

您可以设置 msbuild 以在同一项目中生成单独的程序集。默认情况下，这不是 VS2008 所做的，但并不难做到。

使用 msbuild 可以轻松完成这些事情。

【参考方案11】：

我实际上仍在尝试自己解决这个问题，但是这里的 MSBuild 有一个很大的好处：通过直接调用 msbuild.exe 使用相同的构建文件进行本地持续集成，同时还能够使用 VSTS 的服务器- 与相同构建文件的持续集成（尽管很可能是不同的属性/设置）。

即与 TeamCity 对 MSBuild 脚本的支持相比，VSTS仅支持 MSBuild 脚本！我过去通过从 MSBuild 执行 NAnt 解决了这个问题；我见过其他人推荐这种做法以及相反的做法，但它对我来说似乎很笨拙，所以如果我能避免它，我尽量不这样做。因此，当您使用“完整的 Microsoft 堆栈”（VSTS 和 TFS）时，我建议您坚持使用 MSBuild 脚本。

【参考方案12】：

Nant 具有更多开箱即用的功能，但 MSBuild 具有更好的基本结构（项目元数据岩石），这使得构建可重用的 MSBuild 脚本变得更加容易。

MSBuild 需要一些时间才能理解，但一旦你理解它就会非常好。

学习资料：

Inside the Microsoft Build Engine: Using MSBuild and Team Foundation Build 作者：Sayed Ibrahim Hashimi（2009 年 1 月） Deploying .NET Applications: Learning MSBuild and ClickOnce by Sayed 作者：Y. Hashimi（2008 年 9 月）

【讨论】：

我听到的关于 msbuild 的最有说服力的论点是 clickonce。但是，我发现 clickonce 从根本上是有问题的，所以我避免使用它，并将其用作反对 msbuild 的一个很好的论据。

为什么 ClickOnce 的问题（我不同意）对 MSBuild 有任何影响？

【参考方案13】：

我看不出有任何改变的理由。 MsBuild 本身将您锁定在您正在使用的框架中。如果您使用 NAnt，您可以在许多框架中使用它，并使用 msbuild 来实际为您完成构建任务。

在这方面我是 NAnt 的粉丝，因为它让你从框架中解耦了一点。

我创建了一个将约定放入自动构建的框架，并在 NAnt 上构建了它。它被称为 UppercuT，它是非常容易使用的构建框架。

自动化构建就像 (1) 解决方案名称、(2) 源代码管理路径、(3) 大多数项目的公司名称一样简单！

http://code.google.com/p/uppercut/

这里有一些很好的解释：UppercuT

【参考方案14】：

与 Visual Studio 集成的 MSBuild 可以减少程序员使用构建系统的摩擦。这主要归结为他们只需要去“构建解决方案”就可以了，而不是必须使用自定义构建步骤和其他类似的东西，或者更糟糕的是，迫使开发人员通过启动某种外部脚本来构建。

现在，我主要倾向于 MSBuild 而不是 NAnt，因为它更简单。当然，NAnt 有更多的功能，更强大等等，但它很快就会失控。如果您和您的构建工程师有纪律保持 NAnt 脚本简单，那么一切都很好。然而，我已经看到太多基于 NAnt 的系统走向南方，以至于没有人知道它在做什么了，除了做相当于一个好的 ol'printf 之外，没有真正的方法来调试它。当您开始使用一些 if/else 语句或 for 循环时，恕我直言，这就是开始闻起来的地方。

另一方面，MSBuild 具有基于元数据的坚实基础和不太冗长的语法。它的简单性（或缺少功能……取决于您如何看待它）迫使您通过新任务在 .NET 代码中编写逻辑，而不是在 XML 标记中编写逻辑。这鼓励了可重用性，最重要的是，让您可以在真正的调试器中实际调试您的构建系统。

MSBuild 的唯一问题是不那么偶然的错误（尤其是在第一个版本中）或晦涩难懂的行为（尽管已记录在案）。而且，如果那是真正困扰您的事情，那就是与 Microsoft 联系在一起。

【参考方案15】：

我从 NANT 切换到 MSBuild。该项目在.Net 4.0 中运行。

我在南特的经历很好。这个项目有点死了。当 .Net 4.0 出现时，是时候重新评估构建过程了。

自从 Nant 上次发布以来，MSBuild 已经取得了很大进展。在这一点上，MSBuild 是要走的路。它易于使用，有许多扩展。我用一天半的时间重写了我的 Nant 脚本。 MSBuild 脚本是 Nant 脚本大小的 1/3。

Nant 脚本中的大部分工作是设置不同的环境。在 MsBuild/.Net 4.0 中它是内置的。

【参考方案16】：

我使用 MSBuild 和 Nant，因为当前版本的 Nant 还不能编译 .NET 3.5 应用程序（当 .NET 2.0 首次出现时也是如此）。

【参考方案17】：

我能看到使用 msbuild 的唯一原因是您是否想使用像巡航控制这样的自动构建服务器。如果你不打算切换，那我就不管它了。

【讨论】：

cruisecontrol.net 具有开箱即用的 nant 和 msbuild 任务

【参考方案18】：

我使用 Nant，我喜欢它。由于以下原因，我使用了 MSBuild 并讨厌它：

Microsoft 强迫您遵循他们自己的构建过程，这对他们的行为是如此固有，以至于我至少无法使其工作（我必须编译 NET1.1，所以我不得不混合使用 Nant 和 MSbuild） .我知道您可以创建自己的 MSBuild 文件，但我认为理解和维护它很复杂。

执行文件操作的项目类型太难理解了。您可以让 Nant 做完全相同的事情，而且更容易和直接（我必须创建一个 ItemType 列表，然后传递给文件操作）。

在 MsBuild 中您必须创建自己的任务 dll，在 Nant 中您可以这样做，或者您可以在脚本中嵌入 C# 代码，这样更容易推进并构建整个项目。

Nant 适用于 Net1.1，MsBuild 不适用。

要安装 nant，我什至可以解压缩并在自己的存储库中定位以运行它。安装 MsBuild 要困难得多，因为它依赖于 Visual Studio 等的许多东西（也许我在这里错了，但这似乎是事实）。

这些都是我的意见...

【讨论】：

MSBuild 4.0 支持内联任务 - 请参阅 msdn.microsoft.com/en-us/library/dd722601.aspx。

好吧，但那是在 VS2012 中。我说的是一个 VS2003 应用程序。让我非常沮丧的是，MS 强迫你升级整个开发堆栈以获得新功能。如果他们可以单独释放每个东西，那么痛苦会少得多。