WiX：存储库和存储库/构建服务器集成

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

---

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

因为我读了很多关于组件规则的书，而且人们违反了这些规则就会下地狱，所以我决定使用石蜡作为收割机。此工具能够更新现有组件列表，因此不会为现有组件重新创建新的GUI

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

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

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

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

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

---

那么，我如何确保我的guid在构建之间保持稳定，而不依赖开发人员在提交解决方案之前构建他们的解决方案呢？上述两种方法似乎都不能让我满意，但我现在能想到的就是这些方法。

就我而言，只有当多个安装程序共享具有相同GUID（即完全相同的资源）的组件时，组件规则才会真正发挥作用或者您正在使用wixlib或合并模块，这些模块将作为不同安装程序的一部分提供

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

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

我总是将guid元素保留为

guid='*'

，这样我就知道在我的多个产品中，我的任何组件中都不会有任何guid冲突

---

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

不完全正确。如果并且仅当您提前计划RemoveExistingProducts，以便在重新安装新的GUID之前，将文件从系统中删除时，将组件GUID从一个版本更改为另一个版本是可以的。这种方法适用于没有那么多文件的小型安装程序，但随着安装程序的增长，您会感到有两倍的IO要做，即删除然后重新安装，而不仅仅是覆盖您的文件。简而言之，这取决于您，但在使用建议的方法之前，您应该仔细考虑您的应用程序可能会有多大

多谢各位。目前，我可能会这样做：忽略组件规则，只要求用户进行完全重新安装，而不是升级。这不是一个理想的解决方案，但它确实起到了作用。