当前位置：首页> 正文

关于构建过程：我应该从nant切换到msbuild吗？

Should I switch from nant to msbuild?

我目前使用nant，ccnet(巡航控制)，svn，mbunit。我使用msbuild进行sln构建只是因为它更易于安装。

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

更新：有什么引人入胜的功能会导致我从nant转到msbuild？

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

另外，如Ruben所述，CodePlex上还有SDC Tasks任务。

为了获得更多乐趣，在CodePlex上提供了MSBuild扩展包，其中包括一个twitter任务。

我的建议恰恰相反-避免像瘟疫一样使用MSBuild。 NANT可以很容易地设置您的构建以进行自动测试，部署到多个生产环境，与用于进口环境的CruiseControl集成，与源代码控制集成。我们在使用TFS / MSBuild(使用TFSDeployer，自定义Powershell脚本等)方面经历了很多痛苦，以使其能够立即使用NANT进行处理。不要浪费你的时间。

使用MSBuild的最引人注目的原因(至少在.NET 3.5及更高版本中)-构建引擎可以同时构建。

这意味着在拥有多个内核/处理器的情况下，构建速度将大大提高。

在3.5之前的版本中，MSBuild并未进行并行构建。

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

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

希望有帮助！

编辑：@ChanChan-@Jon提到Nant不会构建.NET 3.5应用程序。这可能足以改变或至少并行使用它们。随着我更加朝着MSBuild迈进，我可能不是最有见地的人，重点介绍使用这两种技术的任何其他热门产品。

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

NAnt已经存在了很长时间，并且是相当成熟的产品，而且IMO更易于使用。如果您对构建可在Mono以及.NET和Silverlight下运行的应用程序感兴趣，那么有很多社区专业知识可以利用，并且它也是跨平台的。开箱即用，它的功能比MSBuild多得多。哦，是的，您可以从NAnt调用MSBuild(确定，从NAntContrib):-)

不利的一面是，NAnt及其姊妹项目NAntContrib似乎停滞了，最新更新是在2007年末。

我所看到的MSBuild的主要优点是，它随.NET Framework一起提供，因此它是一种较少安装的产品。而且还有更积极的发展(尽管在某些地方可以赶上较早的NAnt)。

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

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

除非您有令人信服的理由(至少)，否则不要切换。
NAnt是开源的，如果不是，那么我将无法自定义我们的构建系统，而MSBuild则不是。
NAnt可以轻松运行MSBuild，但我不确定其他方法。
如果您使用VS2005或更高版本，则已经为您编写了MSBuild脚本(项目文件是MSBuild文件。)
如果使用NAnt，并且使用VS编辑项目文件，设置和配置，则必须编写转换器/同步工具以从VS Project文件更新NAnt文件。

我们也从nant切换到msbuild。如果您的构建是相当标准的，则设置它不会有很多问题，但是如果您有很多特定的构建任务，则必须编写自定义ms构建任务，因为msbuild的自定义任务会更少。

如果您想显示合理的构建结果，则必须使用自定义记录器等。整个团队的构建还不如Nant成熟。

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

@布拉德·里奇

I generally wouldn't switch between them unless there was a compelling feature that was missing

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

到目前为止，我的回答是非常不错的，"不打扰"。

我认为它们在功能和易用性方面都相对可比。仅仅基于C＃，我发现msbuild比nant更易于使用，尽管这并不是切换的迫切理由。

南特究竟对您没有做什么？还是只是希望您可能缺少一些很棒的功能？ :)

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

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

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

即，与TeamCity对MSBuild脚本的支持相比，VSTS仅支持MSBuild脚本！过去，我是通过执行MSBuild的NAnt来解决这个问题的。我已经看到其他人也推荐这种做法以及相反的做法，但是对我来说似乎有点不合时宜，所以如果可以避免的话，我尽量不要这样做。因此，当您使用"完整的Microsoft堆栈"(VSTS和TFS)时，建议只使用MSBuild脚本。

Nant具有更多现成的功能，但是MSBuild具有更好的基本结构(项目元数据结构)，这使得构建可重用的MSBuild脚本变得更加容易。

MSBuild需要花一些时间来理解，但是一旦完成，它就会非常好。

学习资料：

在Microsoft Build Engine内部：使用MSBuild和Team Foundation Build
Sayed Ibrahim Hashimi(2009年1月)
部署.NET应用程序：Sayed学习MSBuild和ClickOnce
Y.Hashimi撰写(2008年9月)

我看不出有任何理由要切换。 MsBuild本身会将您锁定在您正在使用的框架中。如果使用NAnt，则可以在许多框架中使用它，并外壳使用msbuild来真正为您完成构建任务。

在这方面，我是NAnt的粉丝，因为它使您与框架略有脱离。

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

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

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

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

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

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

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

MSBuild的唯一问题是不是偶尔发生的错误(尤其是在第一个版本中)或晦涩(尽管已记录)的行为。而且，如果那种事情真的让您感到困扰，请与Microsoft捆绑。

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

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

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

Nant脚本中的许多工作是建立不同的环境。在MsBuild / .Net 4.0中，它是内置的。

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

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

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

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

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

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

用于执行文件操作的ItemTypes很难遵循。您可以让Nant做完全相同的事情，并且更加轻松和直接(我必须创建一个ItemType列表，然后传递给文件操作)。

在MsBuild中，您必须创建自己的任务dll，在Nant中，您可以执行此操作，也可以在脚本中嵌入C＃代码，因此，进行开发非常容易，并且只需构建整个项目即可。

Nant可以与Net1.1一起使用，而MsBuild则不能。

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

这些是我的意见...

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

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