一个初学者的问题，请耐心等待：我只是想知道在什么情况下应该使用像 nant 或 msbuild 这样的构建工具？我正在开发一个中型应用程序（.net 3.0），每个开发人员都在做他的工作，并在他的机器上构建，检查他的代码更改到存储库中。完成后，我将从存储库中获取所有代码，在我的机器上进行干净的构建，然后部署二进制文件。只是出于好奇，构建工具在哪里？
【问题讨论】：
标签： build-process development-process
简短的回答总是。
每个开发人员都应该在签入代码之前使用构建脚本进行构建。构建版本的人员应该使用构建脚本来构建版本。您的构建机器人应该使用构建脚本来构建和测试已签入的代码。
这样做可以让所有开发人员、测试人员和构建机器人拥有一致、可重复的构建。毕竟，The F5 Key Is Not a Build Process。
【讨论】：
听起来您正在使用 IDE 进行构建。它本质上是一个构建工具；您已经在使用一个。当您使用的工具成为问题而非解决方案时，您应该切换工具。
【讨论】：
当您的构建过程超过一个命令时，应使用构建工具。它应该用于将您的标准构建过程归结为一个命令。如果您的构建过程比一个命令长，那么您就有机会因为在构建过程中执行的错过/重复/不正确的命令而导致错误蔓延。
【讨论】：
我认为任何重要的应用程序都需要一个“构建工具”。我们在我工作的地方使用术语持续集成。有非常特殊的情况（例如：我正在构建一个示例应用程序来了解功能 X 的工作原理），但除此之外，您永远不会后悔拥有一个可靠的构建过程。
我猜如果开发团队由一个人组成...我仍然会建立一个包含存储库、构建工具和多套测试的构建系统。 是的，维护构建系统需要时间和金钱，但它会得到回报（我已经为一个由 6 个开发人员开始的项目工作了 40 个月，现在包括大约 30 个开发人员；它确实为我们带来了一些回报次）在质量控制方面，越早发现质量问题，解决问题的成本就越低。
【讨论】：
当您开始发布或构建超过一定数量的手动步骤时（您会注意到它开始变得烦人。）我已经写了一个关于这个主题的旧 blog entry，您可能会觉得有趣。
【讨论】：
如果您想自动化任何事情，最好使用 nant/msbuild。例如： 1. 入住 2. 构建 3. 测试和代码覆盖率
【讨论】：
您是否使用 Visual Studio 进行开发？在这种情况下，您已经在使用 msbuild，因为它是 Visual Studio 的底层构建引擎。实际上，Visual Studio 项目文件只不过是一个 msbuild 脚本。
除此之外，您还可以在专用构建系统上使用构建引擎，这样您的二进制文件就可以在无人参与的情况下构建，而无需安装 Visual Studio。您也可以将其用于单元测试。
【讨论】：
同意并扩展 zacherates 的回答……是的，您应该始终有一些可重复的构建过程。虽然从技术上讲，Visual Studio 项目是 MSBuild 文件，但最好将“官方”构建过程与开发环境分开。
在我看来，无论团队有多大（或多小）都是如此。我在家里使用 NAnt 和 CruiseControl.NET，我倾向于从事的只是临时项目和实验。在工作中，我们使用类似的设置，但 NAnt 脚本的组合方式更加结构化。
绝对值得您花时间研究它。这不是万灵药，但它是一个最佳实践，可以准确了解何时发布了哪个版本，以及在野外发布了什么。能够识别您的编译代码是故障排除战的一半！ :)
【讨论】：