将MSBuild的工作划分为项目

Question

我开始为我的产品创建MSBuild脚本，并遇到困境。代码分为25个左右的项目，有些需要混淆，有些需要强名称签名，其他人将需要链接到一个单一的文件。

所有这些项目应产生3个产品，3个设置。

现在的问题如下：我如何划分MSBuild脚本以最有意义？

是否为每个产品创建脚本？我是否为每个项目创建一个脚本？我是否有一个脚本用于构建，另一个脚本用于混淆等等？

Answer 1

我认为这是每个产品都有脚本的好主意。 最小化发布创建可重用的“子脚本”并将它们导入主脚本（这可以通过Import指令完成）。

<Import Project="..\Steps\Step1.proj" /> 

Answer 2

每个产品的脚本听起来像是要走的路。您可能要考虑拥有任何数量的共享或基本脚本，以导入常见的构建步骤。像Mike Chaliy已经提到的，那么你可以在你的产品的构建脚本使用Import：

<Import Project="..\Shared\Base.proj" /> 

，你可能还需要利用的另一件事是目标和属性的覆盖。这类似于在.Net类中重写虚拟方法。有关更多详细信息，请参阅documentation和MSBuild Team Blog。我知道我通过在包含的脚本中设置默认值，然后在产品构建脚本中根据需要覆盖它们来定制构建行为，从而很好地利用了这一点。例如，我经常在生成之前生成所需的文件，以便将这些目标挂接到BuildDependsOn属性组中。这样，只要我从IDE执行F5，就会生成我生成的文件，从命令行调用构建目标或者构建项目或解决方案。显然，如果您有任何构建步骤运行时间很长或者只需要在特殊情况下运行（如构建安装程序），则需要注意所涉及的内容。