我开始为我的产品创建一个MSBuild脚本，我遇到了一个困境。
代码分为大约25个项目，有些需要混淆，有些需要强名称签名;其他人需要链接到一个文件。
所有这些项目应该产生3个产品，有3个设置。
手头的问题如下：如何将MSBuild脚本划分为最有意义的？
我是否为每个产品创建了一个脚本？为每个项目创建脚本？我有一个用于构建的脚本，另一个用于混淆的脚本等等吗？
答案 0 :(得分：4)
我认为每个产品都有脚本是个好主意。 为了最大限度地减少重复，请创建可重用的“下标”并将其导入主脚本（这可以使用Import指令完成。）
<Import Project="..\Steps\Step1.proj" />
答案 1 :(得分：0)
每个产品的脚本听起来像是要走的路。您可能还需要考虑使用任意数量的共享或基本脚本来导入常见的构建步骤。与已提及的Mike Chaliy一样，您可以在产品的构建脚本中使用Import：
<Import Project="..\Shared\Base.proj" />
您可能还想利用的另一件事是目标和属性覆盖。它类似于覆盖.Net类中的虚拟方法。有关详细信息，请参阅documentation和MSBuild Team Blog。我知道我经常通过在包含的脚本中设置默认值然后在产品构建脚本中根据需要覆盖它们以便自定义构建行为来充分利用这一点。例如，我经常生成在构建之前所需的文件，因此我将这些目标挂钩到BuildDependsOn属性组中。这样，每当我从IDE执行F5，从命令行调用构建目标或以其他方式构建项目或解决方案时，都会生成生成的文件。显然，如果你有任何运行时间很长或只需要在特殊情况下运行的构建步骤（比如构建安装程序），你就会想要确切地关注什么内容。