28

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

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

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

4

18 回答 18

31

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

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

更有趣的是，CodePlex 上有 MSBuild 扩展包，其中包括一个 twitter 任务。

于 2008-08-14T06:14:26.970 回答
27

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

于 2008-08-15T14:49:46.790 回答
12

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

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

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

于 2008-08-15T14:39:02.070 回答
9

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

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

希望有帮助！

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

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

于 2008-08-14T03:43:04.777 回答
3

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

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

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

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

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

于 2009-02-17T04:20:01.623 回答
2

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

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

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

于 2008-12-04T07:37:23.560 回答
2
  • 除非您有非常令人信服的理由（至少），否则不要切换。
  • NAnt 是开源的，如果不是，我将无法自定义我们的构建系统，MSBuild 不是。
  • NAnt 可以轻松运行 MSBuild，我不确定是否可以反过来。
  • 如果您使用 VS2005 或更新版本，则已经为您编写了 MSBuild 脚本（项目文件是MSBuild 文件。）
  • 如果您使用 NAnt，并且使用 VS 来编辑项目文件、设置和配置，则必须编写一个转换器/同步工具来从 VS 项目文件更新您的 NAnt 文件。
于 2009-04-11T11:20:35.247 回答
1

@布拉德·里奇

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

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

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

于 2008-08-14T03:49:42.190 回答
1

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

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

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

就我个人而言，我更喜欢 SCons 而不是他们两个 :)

于 2008-08-14T06:07:42.770 回答
1

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

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

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

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

于 2008-08-15T14:51:51.293 回答
1

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

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

于 2008-11-30T07:41:58.263 回答
1

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

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

学习资料：

于 2009-03-28T23:58:04.260 回答
1

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

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

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

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

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

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

于 2009-05-16T19:04:17.697 回答
1

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

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

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

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

于 2009-10-16T17:36:47.233 回答
1

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

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

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

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

于 2010-06-11T14:52:13.407 回答
0

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

于 2008-08-14T03:53:09.687 回答
0

我能看到使用 msbuild 的唯一原因是您是否想使用自动构建服务器，如巡航控制。如果您不打算切换，那么我将不理会它。

于 2008-08-14T04:06:00.847 回答
0

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

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

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

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

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

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

嗯，这些是我的意见...

于 2012-07-30T17:21:25.567 回答