2

简短版本：如何确保我的组件 GUID 在构建服务器上使用石蜡保持稳定？

我目前正在开发一个应该通过 WiX 部署的项目。由于这是一个网络项目，它包含许多文件（仍处于早期阶段，已经有近 200 个文件）。此外，在开发过程中，文件会不断添加和删除，因此手动维护 WiX 组件列表根本不是一种选择。

由于我阅读了很多有关组件规则的内容，并且违反它们的人会下地狱，因此我决定使用石蜡作为收割机。此工具能够更新现有组件列表，因此不会为现有组件重新创建新的 GUID。

但是，当创建一个新组件时，该工具会分配一个新的 GUID。即使组件文件相同，初始 GUID 在不同的机器上也会不同，甚至只是在不同的时间。

因此，很明显，我需要一个中央机构来修复初始 GUID。我的想法是提交空的组件列表，然后由构建服务器在构建时调用 Paraffin 填充。因此，当我只分发由构建服务器创建的 MSI 时，我可以确定组件规则得到遵守。

但是，这种方法的问题是，如果构建服务器崩溃或清空其本地存储库，我无法跟踪我的 GUID。我正在考虑让构建服务器将生成的组件列表提交到我的存储库，但这似乎不是一个干净的想法。

我想到的另一个解决方案是让所有开发人员在提交之前构建（因此称为石蜡）。因此，每个开发人员都会为其新添加的文件创建初始 GUID，并将它们提交到组件列表。

这种方法的明显问题是：人们（例如开发人员 A）在提交之前会忘记构建。因此，在这些情况下，构建服务器将为新文件创建初始 GUID，但这些也将仅存储在本地。几次提交之后，开发人员 B 将出现并构建解决方案，为开发人员 A 创建的文件创建一个新的 GUID。然后他将提交包含此 GUID 的组件列表，构建服务器将检查它。现在，构建服务器已经获得了一个包的 GUID（由开发人员 A 创建），它之前使用了一个不同的（自己创建的）GUID，即使文件在此期间没有更改。

那么，我如何确保我的 GUID 在构建之间保持稳定，而不依赖于开发人员在提交之前构建他们的解决方案？上面列出的方法对我来说似乎都不满意，但我现在能想到的就只有这些了。

4

2 回答 2

1

不完全正确。当且仅当您提前安排 RemoveExistingProducts 以便文件在重新安装新 GUID 之前离开系统时，才可以将组件 GUID 从构建更改为构建。这种方法适用于文件不多的小型安装程序，但随着安装程序的增长，您会感到需要执行两倍的 IO，因为您删除然后重新安装，而不是仅仅覆盖您的文件。简而言之，这取决于您，但在采用建议的方法之前，您应该仔细考虑您的应用程序可能会变得多大。

于 2013-01-15T21:15:13.097 回答
1

就我而言，只有当您有多个安装程序共享具有相同 guid 的组件（然后应该是完全相同的资源）或者您使用的是 wixlib 或合并模块时，组件规则才真正发挥作用然后作为不同安装程序的一部分包含在内。

根据您上面所说的，对我来说，听起来您不会这样，为每个构建使用不同的组件 guid 并没有什么坏处。这只是意味着当您升级网站时，未更改的文件将被删除并在不同的组件 guid 下重新安装。恕我直言，只要安装程序正确安装站点运行所需的所有文件并且不从其他产品中删除组件，这并不重要。

如果您使用MajorUpgrade元素，旧产品将在安装新产品之前完全删除，因此两个版本之间共享的任何组件 guid 都将被删除，然后重新安装。

我总是只留下我的 guid 元素，Guid='*'因为这样我就知道在我的多个产品中的任何组件中永远不会有任何 guid 冲突。

^ 我知道这在理论上是不正确的，但在这个用例中它是正确的。

于 2013-01-09T11:28:07.250 回答