简短版本：如何在构建服务器上使用Paraffin确保我的组件GUID保持稳定？
我目前正在开发一个应该通过WiX部署的项目。由于这是一个Web项目，它包含许多文件（仍处于早期阶段，已有近200个文件）。此外，在开发过程中，会不断添加和删除文件，因此无法手动维护WiX组件列表。
由于我阅读了很多关于组件规则的内容以及人们打破它们的地狱，我决定选择Paraffin作为收割机。此工具能够更新现有组件列表，因此无法为现有组件重新创建新GUID。
但是，创建新组件时，该工具会分配新的GUID。即使组件文件相同，初始GUID在不同的机器上也会有所不同，甚至只是在不同的时间。
所以，显然，我需要一个中央权限来修复初始GUID。我的想法是提交空组件列表，然后由构建服务器在构建时调用Paraffin来填充。因此，当我只分发构建服务器创建的MSI时，我可以确定正在遵循组件规则。
然而，这种方法的问题是，如果构建服务器崩溃或清空其本地存储库，我无法跟踪我的GUID。我正在考虑让构建服务器将生成的组件列表提交到我的存储库，但这似乎不是一个干净的想法。
我想到的另一个解决方案是让所有开发人员在提交之前构建（并因此调用Paraffin）。因此，每个开发人员都会为新添加的文件创建初始GUID，并将它们提交到组件列表。
这种方法存在明显的问题：人们（例如开发人员A）在提交之前会忘记构建。因此，在这些情况下，构建服务器将为新文件创建初始GUID，但这些GUID也只会存储在本地。稍后提交一些提交，开发人员B将出现并构建解决方案，为开发人员A创建的文件创建新的GUID。然后，他将提交包含此GUID的组件列表，构建服务器将检查它。现在构建服务器已经为一个包获得了一个GUID（由开发人员A创建），它之前使用过不同的（自创）GUID，即使这些文件在此期间没有改变。
那么，我怎样才能确保我的GUID在构建之间保持稳定而不依赖于开发人员在提交之前构建他们的解决方案？上面列出的方法对我来说似乎都不满意，但我现在都能想到。
答案 0 :(得分：1)
就我而言，当你有多个安装程序共享具有相同guid的组件（应该是完全相同的资源）或者你正在使用wixlib或合并时，组件规则才真正起作用模块，然后作为不同安装程序的一部分包含在内。
从你上面所说的，对我而言，听起来并不像你这样，每个版本都有不同的组件指南是没有害处的。这只是意味着当您升级网站时，将删除未更改的文件并在不同的组件guid下重新安装。只要安装程序正确安装了网站运行所需的所有文件并且不从其他产品中删除组件，恕我直言并不重要。
如果您使用MajorUpgrade元素，旧产品将在安装新产品之前完全删除，因此将删除两个版本之间共享的任何组件guid，然后重新安装反正。
我总是将我的guid元素保留为Guid='*'，因为我知道在我的多个产品中，我的任何组件都不会发生任何guid冲突。
^我知道这在理论上并不正确，但在这个用例中它是。
答案 1 :(得分：1)
不完全正确。当且仅当您提前安排RemoveExistingProducts以便在重新安装新GUID之前文件不在系统之外时，将组件GUID从构建更改为构建是正常的。这种方法适用于没有太多文件的小型安装程序，但随着安装程序的增长，您将感觉到要执行多次IO操作，因为您删除然后重新安装，而不是仅仅覆盖您的文件。简而言之，这取决于您，但在开始使用建议的方法之前，您应该仔细考虑应用程序可能会有多大。