[Wix5] Installer handles upgrade as side by side install instead?

[michaelgburton]

My installer project uses a Burn bundle to wrap a custom MSI along with a few ExePackage dependencies, and it uses the MajorUpgrade element to specify the behavior for package upgrades (nothing fancy, just disallow downgrades). I haven't specified ProductCode (so it should autogenerate per build), and I have static UpgradeCodes for both the bundle and the MSI package.

My expectation with this configuration is that my installer will detect the existing install and try to upgrade my package. But what actually happens when I try to install a later version - version 2.1.65 - over an earlier version - 2.1.43 - is that I see both versions in the Programs list and no indication in my log file that it even enters upgrade mode.

Is there something I'm likely missing here? Is there a way to test and debug this besides reviewing install logs?

[michaelgburton]

So here's what I'm thinking might be happening, based on testing and extensive log reviews, plus looking around the internet for similar situations:

1. My upgrade IS actually working, but the old version of the software doesn't uninstall completely.
2. The old version's uninstall is incomplete because I have INIFile entries that set up configuration in %PROGRAMDATA% at install time. The config is required for a service that should start on install, and the parent component of the entries is set to Permanent because the config itself sometimes needs to persist beyond uninstall
3. On "upgrade", the software uninstalls everything except for these INI entries, which then prevent the MSI from being completely uninstalled.
4. If I'm correct about the problem, well...I was never completely comfortable with the INI setup using a Permanent component, but this would appear to force my hand towards altering how I'm doing things.
5. Which is a problem I don't know how to solve. The fact that my configuration ends up in %PROGRAMDATA% is the linchpin here - to enable that, I run the INI configuration inside the Burn engine, which avoids requiring the bootstrapper itself to run as Admin.
6. But that registers those config elements for uninstall, and I don't want to remove the INI entries except as part of a (user-controlled RemoveFolderEx action during uninstall.
7. But I don't want to preserve the component at the cost of losing the ability to upgrade cleanly.

I guess the way folks usually do something like this is CustomAction, running a utility executable in a privileged context without registering hooks that affect uninstall and maintenance operations? Conceivably I could also use the "unpatchable" blank-GUID option for the component, but that feels worse again.

Anyone feel like weighing in on how they accomplish this kind of "sort-of-permanent" component?

[wmanning]

Setting a component as Permanent should not prevent the MSI from being uninstalled; it will just prevent that component from being uninstalled.

MSI installers can install the same components. If this happens there are two references to the component in the registry. Latter if one MSI is uninstalled the component it still there as there would still be one reference left. The permanent attribute (per the docs) just adds an extra reference on install so that on uninstall there is still one reference and thus the component will not be uninstalled.

Is burn, your MSI, and the exe packages all built using the same version of WiX? Seen others here have issues if some are built with say Wix 3.x and some with Wix 4 or 5.

MSI has four version fields but the last one is ignored so that could cause it as well. Burn and it's versions do not have that behaviour though.

[michaelgburton]

Is burn, your MSI, and the exe packages all built using the same version of WiX? Seen others here have issues if some are built with say Wix 3.x and some with Wix 4 or 5.

All are built with Wix 5, so this shouldn't be an issue

MSI has four version fields but the last one is ignored so that could cause it as well. Burn and it's versions do not have that behaviour though.

My versions differ in the third field anyway, so this won't be the issue.

Thanks for the reminders, though!

[michaelgburton]

Further information about this problem - I've created a couple of test versions of my package (v2.1.66 and v2.1.67), differing only in version number, and in the log for the bundle during the upgrade Apply, I see the following line:

[1B7C:1080][2024-11-08T09:34:36]i325: Registering dependency: {FA2C6EEF-8F67-448B-9D41-1E128DE57DAB} on package provider: {7BABFBAD-3B23-40C8-93A7-4228A7205BC5}_v2.1.66, package: MyInstaller

Is this because I've got prerequisites in the bundle? I'm not sure I understand why this registration happens or where it's coming from otherwise; I don't have any elements in my bundle or package that explicitly set dependencies, and my prerequisites are all being installed as permanent, so I would have expected they wouldn't need any additional handling.

This problem is kind of the last straw for me, to be honest. Not being able to cleanly upgrade between versions for reasons that are opaque to me means I need to move on to another framework. It's too bad, really. Wix is a very interesting project, but the amount of knowledge required to use it for even a simple install seems to be overwhelming.

[robmen]

A bundle registers a dependency on every package it contains for reference counting purposes. Two bundles could install the same MSI. Uninstalling one bundle should not remove the MSI since the other bundle is still using it.

Fundamentally, though, I don't really understand what the problem is you're having. You describe the .wxs code you've written but never shared it, so its hard to know if you have obvious typos or mistakes in your code. You also provide your own guesses at what you think is going wrong but never share the actual log files. In the end, it isn't easy to see "at a glance" if anything is wrong.

In the end, major upgrades usually just work. The fact that yours isn't working probably means you've doing something really strange in your MSIs or you have state left over on your machine. As noted above, nothing you've described thus far really provides enough detail to make sense of what's going on.

This problem is kind of the last straw for me, to be honest. Not being able to cleanly upgrade between versions for reasons that are opaque to me means I need to move on to another framework. It's too bad, really. Wix is a very interesting project, but the amount of knowledge required to use it for even a simple install seems to be overwhelming.

Best of luck to you.