问题标签 [major-upgrade]

我在 WiX 中有一个大程序，它使用了一堆 MSI、C# 自定义操作程序、UI、引导程序，你说它，它就在那里。

我遇到了这个问题：当我进行重大升级时，以前的版本没有被删除。也就是说，如果我从版本 1.0.0.x 升级到 1.1.0.x，程序和功能显示这两个版本都安装在机器上。

这是一个常见问题，在 SO 上有很多解决方案。他们都没有为我工作——如果有关于这个的帖子，我已经试过了。

有人告诉我，重大升级中的组件之间存在一对一的关系。也就是说，对于每个移除的组件，都必须添加另一个组件。当它不是一对一的关系时，旧版本没有被删除——因为仍然有旧组件挂起。

有没有办法确定哪些组件挂了？比如，在日志文件中还是什么？如果我能确定 MSI 有什么问题，我可以更积极主动地解决问题。

编辑：

虽然我还没有解决问题，但感谢厄尔曼先生的建议，我可能走上了正轨。

我创建了那个注册表项，但是......它似乎没有做任何事情。但是，我确实在我的卸载日志中搜索了“Disallow”这个词，我发现了这个短语 9 次：

此外，此短语出现在“Disallow”短语的每个分组之前：

这给了我一些东西可以继续。但是，我似乎找不到提到的 GUID！它们不在我的解决方案中，也不能在注册表中搜索。除了搜索注册表之外，有没有办法（Windows 7 32 位）找出特定 GUID 对应的组件？

我正在使用 WiX 3.8（我认为是最新的稳定版本），我似乎无法在重大升级期间获得不会卸载并重新安装的配置文件。

SO上有很多关于这个的问题——很多答案都指向这个网站作为一个很好的答案。但是，给出的建议不起作用（对我来说）。

该网站所说的是将每个配置文件放在自己的组件中，并将文件标记为组件的关键路径。像这样的东西：

伟大的。接下来它说在InstallFiles操作之后安排RemoveExistingProduct，如下所示：

问题是，当我编译时，我得到这个错误：

InstallExecuteSequence 表包含在两个不同位置声明的操作“RemoveExistingProducts”。请删除其中一项操作或在其中一个元素上设置 Overridable='yes' 属性。

这个人也有这个问题，但他似乎已经解决了。为他解决的问题是在 中添加了一个调度属性，这有效地摆脱了“两个不同的位置”声明问题（我猜）：

所以当我替换计划更改属性（其中包含一个属性本身，我猜），它不仅不起作用——配置文件在升级过程中被删除和替换——它会导致更多的怪异。我的项目有一个带有很多 MSI 的引导程序，虽然我获得了用于安装包含配置文件的 MSI 之后的所有 MSI 的日志文件，但它们并没有安装。

让我重复一遍：日志说安装了 MSI，但没有安装。我在日志文件中找不到的某个地方可能存在回滚，但是阅读 MSI 日志文件时，安装看起来很顺利。

有谁知道在 Wix 3.8 的主要升级期间不删除和重新安装配置文件的方法？我上面提到的是我能从互联网上找到的最好的信息，但是我在 SO 上尝试了几乎所有的东西都无济于事。

我真的很抱歉我是多余的。我已经检查了该站点本身以及其他一些站点中的许多其他帖子。如果不卸载和重新安装服务，我将无法进行主要升级。我正在更改产品代码和版本，UpgradeFileComponent 是升级的一部分。其余的都与 1.0.0 中的相同。我正在做 POC，因此只想做这个小改动（不是作为补丁，而是作为主要升级）。以下是我的 Product.wxs。我不包括 ServiceAccountDlg、Variables.wxi 或 en-us.wxl 等其他内容的标记，因为它可能会使它变得很长。谁能帮帮我吗？我已经尝试过 WIX_UPGRADE_DETECTED、UPGRADINGPRODUCTCODE 等，但无法使其正常工作。每次，该服务都会被卸载并重新安装。我正在通过以下方式验证这一点。服务启动后，它会在 ProgramData 中创建一个日志文件，并每隔 5 秒将其追加一次。在卸载 MSI 期间，我正在删除此日志文件及其文件夹。重新安装并重新启动服务后，将再次创建日志文件。有了这个，我能够弄清楚该服务总是随着主要升级而重新安装。我只希望在不重新安装服务或卸载任何其他组件的情况下部署新文件。我从一些人那里听说，该工具集会检查更改的文件并仅在发生更改时重新安装它们。但情况似乎并非如此。我也尝试过使用具有各种值的 Schedule 属性，但没有运气。任何帮助都会非常棒。我已经尝试了这么多天没有任何运气。

我有问题。我想在安装过程中升级我的应用程序，但我遇到了版本控制问题。我使用格式的版本号，例如 5.5.789.0，一些新版本的版本号格式为 5.5.12.1。我知道安装程序仅适用于版本中的前三个数字，因此 MajorUpgrade 不适合我。在这种情况下不会安装新版本。有没有一种方法可以让我在一些自定义操作中检查版本并从那里计划升级？我无法更改版本控制，因为应用程序构建会经过一些自动后处理，这些后处理也仅适用于前三个数字，并且无法更改该行为。

感谢您的建议。

编辑：我正在使用 WiX#。

我遵循了官方的主要升级指南，但我似乎遗漏了一些东西。这是我的MCVE：

它所做的只是简单地安装一个文件作为示例。到现在为止还挺好。现在，我要做的就是添加另一个Component，File当然也可以添加相应ComponentRef的 in Feature。我特别保留Version原样：31.00.0000。我所期望的是新安装程序不会执行重大升级，但它会执行。为什么？此外，现在添加/删除程序中有 2 个条目。

请帮我找出我在这里缺少什么。谢谢。雷菲尔。

更新：发布问题让我再次重新阅读文档，我发现元素中的AllowSameVersionUpgrades东西MajorUpgrade应该设置为yes. 这次添加/删除程序中只有一个条目，但它仍然执行主要升级。为什么？

我们有一个安装程序，它需要在安装时重新启动，但它也在卸载时重新启动。卸载时有没有办法防止重新启动？

这就是我们目前所拥有的：

提前谢谢了！

在重大升级期间处理 web.config 文件的标准方法是什么。我知道在升级期间如何处理未版本控制的文件，如果文件已被用户修改，则不会替换该文件。

有没有办法处理在配置文件中添加了新条目与需要安装的最新安装程序捆绑在一起的情况，并且还保留了用户在 Wix 的主要升级期间修改的现有条目。

我正在使用 WIX 为我的应用程序创建一个 Windows 安装程序，因此，我以通常的方式开始：

因为Id设置为*，所以每次我构建 MSI 时它都有不同的 id，但UpgradeCode保持不变。当版本有升级时（例如1.0.0.2），这成功地实现了用新的替换旧的。

该MajorUpgrade条目会阻止安装较低版本，例如 1.0.0.0。

如果我运行完全相同的 MSI 文件，它会显示一个对话框来修复、卸载或更改安装参数。

我的问题是，如果我重新构建 MSI 并运行新的 MSI，它会像没有安装其他 Project X 副本一样安装，并且用户最终会在 Windows 应用程序和功能中获得两个条目。

有没有办法防止这种情况？有没有办法在每次构建时不必修改（和提交）我的.wxs文件或另一个构建文件来防止它？我试图让我的构建尽可能自动化，并且每次都必须打开一个文件进行更改，这真的很烦人。

关于将版本号传递给candle.exe，它并不能解决问题。这仍然需要将版本号存储在 repo 中，为安装程序的每个测试创建提交。无论我必须在wxs文件中手动写入数字还是必须在pom.xml（这是构建工具的配置）中手动写入数字，或者它是否在构建过程中生成并存储在文件中然后我必须提交到文件中，这都是同样的问题回购，以便我和所有参与的开发人员的数量保持单调增加。

万一这很重要，我使用 Git 作为我的源代码控制系统，使用 Maven 作为我的构建工具，heat.exe调用. 具体来说，我没有使用 Visual Studio。candle.exelight.exe

关于类似的问题WIX。相同版本不同产品代码如何进行重大升级？，问题和答案都假定.wxs每次构建安装程序进行测试时都可以修改文件以增加版本号。我不认为这是可以接受的。我已经知道这是可能的，因为这就是MajorUpgrade我在这个问题中注意到的。

重大升级会自动卸载现有版本并安装当前版本。

不幸的是，主要升级仅适用于以下项目类型： - 基本 MSI - InstallScript MSI - MSI 数据库 - 转换

它不适用于“InstallScript”项目类型。我们如何才能实现主要升级在“InstallScript”项目类型中提供的功能。我们希望在继续当前安装之前自动卸载现有版本。

在继续安装之前，我尝试使用 UninstallApplication InstallScript 函数以及从 InstallScript 代码调用 msiexec 手动卸载，但这两种方法会显示两个对话框。一个是确认删除产品，另一个是在完成删除后单击“完成”按钮退出卸载。

我们想要主要升级提供的没有弹出对话框的内容。

我们无法使用“InstallScript MSI”项目类型，因为我们遇到了此项目类型的一些问题。

此外，我们不想将现有的“InstallSript MSI”项目转换为“Basic MSI”，因为我们想重用我们拥有的安装脚本，并且转换为“InstallScript”项目类型将允许我们这样做。

感谢您的回复斯坦。

对于基本 MSI，我在 InstallShield 中看到了以下文档。不能使用一些全局变量来保存信息似乎是一个缺点。目前我们有“InstallScript MSI”项目，我们有安装脚本，它使用全局变量维护信息。例如，我们可能会查找和存储某些内容，并基于该动态更改对话框中的复选框等。我们还会查找并存储稍后在 installscript 函数在不同阶段执行时使用的信息。但似乎在“基本 MSI”中，每个调用 InstallScript 函数的自定义操作都是独立的，因为它发现和设置的内容不能被另一个自定义操作调用另一个 InstallScript 函数使用。有什么想法吗？

基本微星：

不再在各个 InstallScript 自定义操作调用之间维护全局变量和指针。此外，每个 InstallScript

自定义操作初始化并使用其自己的个人 SUPPORTDIR。因此，您不能使用文件在各个呼叫之间共享信息

在支持目录中。有关详细信息，请参阅全局变量、全局指针和 SUPPORTDIR。

全局变量、全局指针和 SUPPORTDIR

对于 InstallShield 12 及更高版本，当基本 MSI 安装执行 InstallScript 自定义操作时，会加载已编译的 InstallScript

在调用动作之前，它在动作完成后被卸载。因此，每个 InstallScript 自定义操作都以自己的方式执行

具有完整 InstallScript 引擎加载和卸载的会话。此行为与 InstallShield 11.5 及更早版本不同：

已编译的 InstallScript 在 InstallScript 使用的第一个 InstallScript 自定义操作执行之前加载一次，并且它

在完成所有 InstallScript 自定义操作后，在安装结束时卸载。

这种行为变化的一个主要含义是全局变量和指针不再在个体之间维护

InstallScript 自定义操作调用：

• 如果您需要跨多个自定义操作调用存储值，则必须使用一些外部机制，例如注册表、Windows

安装程序属性，或用于存储调用之间信息的外部数据文件。如果您选择在

延迟、提交或回滚 InstallScript 自定义操作，请参阅 Windows Installer 属性和延迟、提交和回滚中的指南

回滚 InstallScript 自定义操作。• 如果您需要在自定义操作调用中使用 COM 对象或其他一些全局对象，您必须为每个

单独的自定义操作调用，以使对象有效。此更改的另一个含义是每个自定义操作都会初始化并使用自己的单独 SUPPORTDIR。因此，您不能分享

使用 SUPPORTDIR 中的文件跨单个调用的信息，因为每个自定义操作调用都将具有自己唯一的 SUPPORTDIR。你

可以使用 FOLDER_TEMP 或其他文件位置共享信息。

请注意，FOLDER_TEMP 可能不是所有 InstallScript 自定义操作的相同路径。如果您有一些 InstallScript 自定义操作

在系统上下文中运行的和一些不在系统上下文中运行的，如果包在提升状态下运行，它们将具有不同的临时路径。这

InstallScript 自定义操作在不同用户的上下文中运行，因此将文件存储在临时目录中并稍后检索它可能不会

在某些场景下工作。

最近我发布了一个版本化的包0.8.3，我现在准备发布一个新包。但是，我正在努力实施Major Upgrade/ Upgrade。似乎该WIX_UPGRADE_DETECTED变量从未填充过。然后我遇到了WiX3 主要升级无法正常工作的地方，接受的答案指出：

4. 所有安装版本（同样，不是文件版本）必须是 1.0 或更高版本。

实际上，暂时将两个软件包的主要版本都设置为 1 似乎可以解决这个问题。但是，我无法追溯更改旧软件包的版本，因为它已经安装在数千台计算机上。在安装新软件包时彻底卸载旧软件包的最佳方法是什么？有没有比设置CustomAction运行更好的方法msiexec.exe /x {PRODUCT-CODE}？