我是一个大系统的开发人员（＆gt;解决方案中的100个项目，> 10万个LOC，> 10个服务，......）并且在过去使用wix安装了这个系统并且它运行良好。现在我需要一种方法来修补（次要升级）部分系统并遇到几个问题。
我当前的Wix设置如下：
无法更改此设置。
设置库项目设置如下：
现在我需要补丁。 我创建了Patch.wxs并为它调用了蜡烛和灯光。我打电话给火炬来获取差异文件。最后想用pyro创建补丁。 使用简单的测试项目，一切都运行良好，但在大系统上 Pyro有一个问题，就是无法找到要安装的文件。 通过我的设置（见上文），我必须使用预处理器变量并在我的wix输出中有一个完整的限定路径（例如：C：\ builds \ myproduct \ prodct.exe作为文件源）。将TFS输出移动到另一个位置后，此路径不再有效。我尝试使用-bt和-bu开关用于pyro，但这只适用于相对路径或命名的bindpaths。
现在我想改变我的wix项目设置以使用命名的bindpaths而不是预处理器变量，但似乎这是不可能的。 heat只能使用预处理器变量或wixvariables，但似乎不可能使用bindpath变量。 heat提供了一个switch -wixvar，它应该创建binder变量而不是预处理器变量，但我什么也没做。
现在我尝试在加热时不使用wix和预处理器变量，并告诉light -bu -bt开关在何处查找文件。但是，如果我没有设置预处理器变量，则生成的文件看起来像Sources \ product.exe。我无法摆脱这个来源。我知道我可以使用xslt转换所有xml并删除Sources但这是一个解决方法，如果没有其他解决方案可行，我只能实现。这也意味着wix工具链存在问题。
看起来pyro只支持bindpath变量，而heat只支持预处理器和wix变量。这似乎真的很疯狂，因为它们应该如何协同工作？
如果我使用lit，light，candle，heat，torch和pyro以及原始构建路径是否已更改（在构建系统中非常常见）并且创建了文件路径，我该如何创建补丁？有加热因此是固定的还是预处理器或wix变量？
答案 0 :(得分：2)
您发现heat并非设计用于修补方案。只有在最近版本的WiX工具集中，生成的GUID才能达到heat成功构建可修补输出的可能性。仍然需要在那里做工作，以便在heat使用良好的情况下进行修补。
最终，我认为答案是简化“原始来源”问题。让所有绑定路径正确设置并使修补成为一个挑战，这是一个难题，甚至更难。我们已经提出了一些想法，但还没有结合在一起。
您始终可以使用基于管理员映像的修补程序。它速度较慢但可以更容易地获得“原始来源”和“目标”。该路径确实会失去过滤功能。
基本上，我们需要在修补方案中做更多工作，以使其更容易。
PS：File/@Source属性路径中的“Source”是“默认绑定路径”的别名。你可以在那里使用bindpath。