问题标签 [major-upgrade]

I have a .msi file created by a program called MSICREATE and doctored using orca as follows...

InstallExecuteSequence Table

InstallUISequence Table

PropertyTable

Added a Upgrade Table

I also assigned a new PackageCode and a new ProductCode so the new msi had different values of PackageCode, ProductCode, and ProductVersion than the previously installed product.

When I run this msi with the product previously installed, the old product is deleted, a new program files directory created and all the files except the .exe reinstalled from the new .msi. A repair will cause the .exe to be created. If the new msi is installed AFTER removing the old product (using control panel add/remove programs), all files including the .exe are installed.

The msiexec log file is mywebspace.wisc.edu/mdorl/msilog/log3.log

The .msi is mywebspace.wisc.edu/mdorl/msilog/sbl_Major_Upgrade.msi

The only things that looks weird to me are the following lines from the log. The first, second, and fourth are files that do get installed, the third is the .exe file that does not get installed. NOTE THE NULL ACTION ON THIS ENTRY.

我有一个 WIX 安装程序，它可以从外部 CAB 文件安装一些未版本控制的文件。

我的问题是我被告知在 InstallInitialize 之前我需要 RemoveExistingProducts 才能正确升级未版本化的文件。但是，它似乎被外部 cab 文件吓坏了，并不断给我一个错误，即该文件不在 CAB 文件中（即使它在）。

如果 RemoveExistingProducts 在 InstallExecute 之后，它第一次使用 CAB 文件正确安装，但在升级过程中不会升级文件

以下是一些片段：

...

...

我根据在这里找到的代码创建了一个安装程序。如果存在应用程序的早期版本，我希望安装程序在安装新版本之前将其删除。

如果是全新安装，一切顺利。

如果是升级，就会发生奇怪的事情。正如预期的那样，旧版本被删除，注册表被更改，快捷方式被放置在桌面上。奇怪的是，安装程序完成后，应用程序文件夹中不存在主文件。

升级后启动时，会弹出一个小的安装程序消息框并指出“请稍候，Windows 正在配置 -app name-..”。在此快速消息之后，该文件应存在于应用程序文件夹中，并且应用程序启动。

但在发布之前，它不存在。我什至在启动应用程序之前尝试重新启动，看看如果文件卡在某种缓存中，是否会放置文件。

有人见过这种行为吗？这有点像这个问题，但每次升级都会发生。

我们正在使用 wix 项目来创建 msi。我们正在尝试进行重大升级。

我们确实更改了产品代码和产品版本并创建了新的 Msi

在机器中安装了新的 msi [注册表项已创建并且 installdir 包含最新文件]。

现在我们在卸载注册表项中看到两个产品代码。我认为旧的 msi 没有正确卸载。

当我们更新产品代码时，它应该会自动处理它，不是吗？不卸载旧版本的原因可能是什么？

We are trying to do Major upgrade. While i was investigating i found 2 approaches.

One is using Upgrade Id and another one approach was Majorupgrade tag.

It seems Majorupgrade is easy to do it seems. But schedule doesn't contain any before installinitialize action.

I am not sure which should be using .

Which one is preferred [and recommended] mostly?

我正在使用带有新的主要升级功能的 Wix 3.5，我还WixUI_Advanced用于允许用户在每用户（默认）或每机器安装范围之间进行选择。

安装具有相同每用户范围的较新版本时，主要升级适用于每用户安装范围。但是，当旧版本安装为 Per Machine 范围时，使用 Per Machine 范围安装新版本实际上不会将旧版本升级到新版本。相反，我在程序和功能中找到了 2 个已安装的实例。

我从 StackOverflow 中找到了这个问题和答案：Wix Major Upgrade and Install Context Issues。Ciprian 的唯一回答是FindRelatedProducts再次执行行动。

我不知道如何FindRelatedProducts再次执行。有没有人试过这个并看到它有效，如果是，如何？

非常感谢。

我有一个非常简单的 WiX 项目（版本 3.7），它安装了一些文件（一个 .NET 程序版本 6.0.0.0）。我已准备好使用 WiX 中的 MajorUpgrade 功能发布新版本 6.0.1.0。

我在 Product 元素中保持 UpgradeCode 相同，并将版本从 6.0.0.0 更改为 6.0.1.0

在安装了 6.0.0.0 的机器上，我运行新的安装程序。

旧版本 6.0.0.0 的删除运行正常（正在删除所有已安装的文件），但是当安装程序继续安装新版本时，缺少 2 个文件：第 3 方 DLL 和第 3 方 EXE（没有已更改）未重新安装。

< ComponentGroup > 中的所有其他文件（一些已修改，一些未修改，包括其他第 3 方 DLL）在主要升级期间正确安装。

如果我在重大升级后单击“修复”，则丢失的 2 个文件会重新出现。另外，如果我是第一次安装 6.0.1.0 版本（不升级，而是在干净的机器上首次安装），那么这两个文件是直接正常安装的。（在多台 Windows 机器上测试（XP、7 和 8）

有人建议什么是错的以及如何解决它？

我正在使用 AjaxControlToolkit，他们决定更改他们的版本编号方案。此处记录了更改：http: //stephenwalther.com/archive/2013/01/24/new-january-2013-release-of-the-ajax-control-toolkit.aspx

基本上，较新的版本具有较低的文件版本（4.1.7.123 比 4.1.60501.0 新，但 7 比 60501 小。）显然，这会导致我的 MSI 出现问题，因为它现在已经看到具有更高版本号的组件在机器上，因此输出：

我将如何去强制安装这个更新但版本号较低的组件？

PS 个人咆哮：AjaxControlToolkit 家伙通过说“是的，我意识到 7.0123 小于 60,919，但我们的数字用完了。”来证明这个数字的合理性。伙计们，4.2.7.123 会起作用的。你用完了第三个数字，很好，你需要增加第二个。

对于我们的 msi，我们没有在现有版本中提及 allusers 属性。所以默认情况下它按照用户进行。

我们的客户使用管理员用户 ID 安装了应用程序，并且该管理员离开了公司。因此，他的用户 ID 不再处于有效状态。

现在他们无法使用另一个管理员帐户迁移到较新的版本（因为它是按用户安装的）。

虽然我们可以更改我们的 msi 以支持所有用户，但它在迁移（重大升级）中不起作用。

似乎只有当我们提供不支持现有版本的全新版本时，我们才能解决该问题。

即使以前的 msi 是每个用户的，是否还有其他解决方法可以提及，现在应该进行重大升级吗？

我们在安装过程中使用 WIX 3.5。

我有一个 WiX 设置

如果在升级过程中发生错误，安装程序会回滚并恢复之前安装的版本。但是，通过自定义操作创建的计划任务会丢失并且永远不会恢复。

我用于创建/删除/回滚任务的自定义操作是：

排队为

CreateScheduledTask-action 有一个条件NOT Installed，我出于测试目的删除了该条件。

谁能告诉我，为了在升级设置回滚时重新创建任务，我需要做什么？PS：我无权访问最初创建任务时使用的域、用户名或密码。