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

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

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

解决方案

回答

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

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

希望对我们有所帮助！

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

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

回答

@布拉德·里奇

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

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

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

回答

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

回答

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

回答

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

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

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

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

回答

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

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

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

回答

使用MSBuild(至少在.NET 3.5及更高版本中)的最有说服力的原因是生成引擎可以同时生成。

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

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

回答

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

回答

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

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

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

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

回答

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

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

回答

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

如果要显示合理的构建结果，则必须与自定义记录器等混为一谈。整个团队的构建还不如Nant成熟。

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

回答

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

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

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

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

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

回答

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

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

学习资料：

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

回答

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

回答

我看不出有任何理由要切换。 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中，它是内置的。