我有一个解决方案,其中包含许多我想使用石蜡来维护包含文件列表的 Wix 项目。
据我了解,您通常会将石蜡指向各个 bin 文件夹以收集所有文件。
当 TFS 构建解决方案时,它会覆盖 OutDir msbuild 属性,这会导致所有构建输出进入一个公共二进制目录,而不是每个项目的 bin 文件夹。
那么在这种情况下人们如何使用石蜡呢?
我已经很多年没用过石蜡了。最新版本可能会满足您的需求,但让我给您一些额外的想法,您可以使用或不使用石蜡。
paraffin、heat和tallow的一个缺点是它们会收集二进制文件,因此它们必须存在,位于适当的文件夹等中。另一种方法是从.sln文件本身和它引用的.proj文件中收集 - 解决方案是大概是产品|包中哪些二进制文件的最终列表。您可能能够在构建时为每个二进制文件自动生成片段,而无需在源代码管理中维护这些片段,也无需实际构建二进制文件。
查看 WiX 3.6+ 中的 MSBuild 集成,尤其是收获目标。如果这对您不起作用,请尝试以下操作:
我们在最近的一个项目中采用的方法完全绕过了热量。我们编写了一个工作流活动来扫描.sln及其.proj引用,并为每个二进制文件直接生成一个 WiX片段——它们都是 XML 文档。第 3 版 UUID 是根据二进制名称、目标文件夹和构建版本生成的(此想法归功于Derek Cicerone),因此ComponentID在构建之间保持一致,但在分支到新版本时会自动滚动。
解决方案中的一些二进制文件(例如测试夹具)我们不想放入安装程序包中,因此我们在.proj文件中注入了一个新的 MSBuild 属性来标记“可安装”(或不可安装)。你可以注入一个属性来指定目标目录——在我们的例子中,所有的二进制文件都应该进入同一个文件夹,所以我们不需要那个。如果您想花哨的话,您甚至可以为此构建一个自定义的 Visual Studio 项目属性页面。
这样做的一个好处是团队中的应用程序开发人员可以简单地向解决方案添加新的二进制文件,或删除现有的二进制文件,安装程序包将在下一次构建时自动同步.msi包中的内容。为安装人员(您真正的)节省了很多麻烦!
您可以结合使用这些方法:扫描解决方案为其构建的二进制文件,然后使用该信息来定位石蜡或加热适当的文件夹|文件以进行收获。