除了编译之外，MSBuild 脚本中应该包含哪些内容？答案

【问题标题】：What should go in an MSBuild Script except compilation?除了编译之外，MSBuild 脚本中应该包含哪些内容？
【发布时间】：2009-03-04 15:44:26
【问题描述】：

我目前正在尝试设置 CruiseControl.net，所以我想知道如何拆分我的任务。

一般来说，我想运行单元测试 (xUnit.net)、帮助文件生成 (Sandcastle) 和 FxCop。

现在我只是想知道我是否应该在 msbuild 配置（“文档”）中指定一个新目标并使用它来运行 SandCastle，或者它是否属于单独的脚本？另外，msbuild 是用来构建一些东西的，所以我猜 ncover、xunit 和 FxCop 不应该是它的一部分，还是应该它们？

msbuild 的预期范围是什么？

【问题讨论】：

标签： .net msbuild cruisecontrol.net

【解决方案1】：

将几乎所有内容都放入 MSBuild 脚本中，以便您和其他开发人员可以通过命令行在本地运行相同的步骤。否则，当构建出现问题时，您必须在 CC 服务器上对其进行调试。不是很好的调试体验。此外，您希望在提交之前在本地运行构建以确保其正常工作。

我不会放入 MSBuild 脚本的几件事是：

SVN 更新，因为 CC 无论如何都必须这样做，并且在进行本地构建时通常不想更新。（嗯，我确实经常输入svn up && msbuild，但它太短了，我不需要将其放入脚本中。）
创建和发布构建报告；同样，这是 CC 的域，在本地没有用处

至于构建您的 MSBuild 文件，您将需要一个“主”构建脚本，您可以使用它来构建所有内容或只是一些目标，例如

MSBuild /t:Build 只是增量构建代码
MSBuild /t:Rebuild 进行干净的重建
MSBuild /t:UnitTest 只运行单元测试
MSBuild 表示最常见的选择，例如，相当于t:Build;UnitTest
MSBuild /t:All 干净地构建代码、文档和设置，运行所有测试并打包结果

您还可以为流行的变体添加“快捷方式”目标。

拥有一个主构建文件并不意味着所有内容都在这个文件中定义；您可以包含其他 msbuild 文件，和/或递归调用 msbuild 来组织您的构建。例如：

主.proj文件应该比较简单；主要是，它应该定义特定于项目的东西，例如要构建的解决方案列表和特定于项目的覆盖
让主文件包含单个 .targets 文件，其中包含目标和默认属性；努力保持这个项目的中立性和可重用性。
如果 .targets 文件变得太大，请将其拆分为单独的文件，例如一种用于代码，一种用于帮助和文档，一种用于设置和打包。让你的主 .targets 文件包含那些子文件，这样你的 .proj 文件仍然只需要包含一个文件
同样，如果需要，您可以拆分主 .proj 文件，例如按子系统。

【讨论】：

【解决方案2】：

我有一个用于单个项目的构建脚本，我只是在构建套件时将它们从 second 构建文件中链接起来......例如，我的 protobuf-net 构建文件处理版本控制 (SVN) ，编译（MSBuild + NAnt for mono），测试（NUnit），打包（zip）等。这是您的构建过程；做你需要的；-p 如果我也可以做部署和文档。

这也取决于你的工作方式；如果您使用 CruiseControl，它可能会为您处理大部分工作。对于我自己，我喜欢命令行“构建”步骤。

【讨论】：