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。如果您的构建是相当标准的，则设置它不会有很多问题，但是如果您有很多特定的构建任务，则必须编写自定义ms构建任务，因为msbuild的自定义任务会更少。 如果您想显示合理的构建结果，则必须使用自定义记录器等。整个团队的构建还不如Nant成熟。 但是真正的好处是与TFS源控制和报告服务集成。如果您没有将TFS用作源代码控制系统，那是不值得的。 @布拉德·里奇
使用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需要花一些时间来理解，但是一旦完成，它就会非常好。 学习资料：
我看不出有任何理由要切换。 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首次出现时，情况也是如此)。 |
