4

I've created an installation package (via WIX) that takes advantage of instance transforms to allow itself to be installed multiple times on one machine. Without giving it a lot of thought, I also added support for major upgrades (as I had done many times previously).

Today, a new version of the product was installed for the first time, and the behavior was not quite what I expected: Even though the installation was targeted at a new instance, it appears that all the other instances (all at an older version) were uninstalled.

In hindsight, this was not particularly surprising because all instances share the same upgrade code. According to the documentation for the FindRelatedProducts action, that and the version are the only criteria for determining what products should be targeted for removal.

How can I author this installation package such that when a new version is installed, only the targeted instance is upgraded, and other instances are left alone?

I suspect the answer may be that I should remove the 'major upgrade' feature altogether, but I've seen several examples of multiple-instance installs that use it, so I'm not sure. Also, it occurs to me that I'm probably not handling the product code correctly because it should be updated with the version number, but the instance transforms use a fixed product code. Somehow I don't think that is the problem here, but I thought I should mention it just in case.

TylerH
  • 20,799
  • 66
  • 75
  • 101
Daniel Pratt
  • 12,007
  • 2
  • 44
  • 61
  • @TylerH I'm not sure any of your edits were particularly warranted, but specifically I'm wondering why you altered the specific and relevant `major-upgrade` tag to the so-generic-as-to-be-practically-useless `upgrade` tag? – Daniel Pratt Sep 09 '19 at 15:29
  • I'm not sure even you buy that line of reasoning. If "upgrade" is so generic that it's useless, what value do you think "major upgrade" provides? What's the useful difference beyond "upgrade" that isn't also covered in the question body? The tag has only two followers, and *no* usage guidance. I've already removed the "minor upgrade" tag from the site as there was no usage guidance or followers on that one (and only about 10 uses). The "major upgrade" tag only has a few questions remaining in it before it, too, is removed. – TylerH Sep 09 '19 at 15:41
  • If you think there is some particular value in having a "major upgrade" tag, please suggest some edits to the tag wiki and wiki excerpt to clarify what it's use might be. If you intended to use "major-upgrade" to signify some use case specific to Wix (e.g. if there's a feature, module, or process within Wix *called* "major upgrade"), then please create a *new* tag ("wix-major-upgrade" would be an ideal name to avoid ambiguity) also with some descriptions in the wiki and wiki excerpt.. – TylerH Sep 09 '19 at 15:44
  • @TylerH Perhaps the `major-upgrade` tag is not particularly useful, but I'm pretty certain it's more useful than the `upgrade` tag, at least in this context. Someone having problems configuring a "major upgrade" for their installation package (as I was) might conceivably try to refine their search using that tag. The `upgrade` tag seems to apply to a broad range of subjects, but perhaps mostly folks having problems with a system post-upgrade, which is not what this question is about. – Daniel Pratt Sep 09 '19 at 16:04
  • @TylerH Whilst I'm questioning the usefulness of things, that includes your comment "I'm not sure even you buy that line of reasoning". It seems to suggest that my comment was disingenuous, which I don't think is at all warranted at this point. – Daniel Pratt Sep 09 '19 at 16:15
  • @TylerH I've added a description for the `major-upgrade` tag, but it is pending approval. I do not believe a rename to `wix-major-upgrade` is appropriate because it is not a WIX-specific concept. I apologize if I've misjudged the situation, but my impression is that you are not very familiar with the topic of this question or the concept described by the `major-upgrade` tag. – Daniel Pratt Sep 09 '19 at 17:36
  • I've reviewed the edit suggestion, but it'll take one more user approving to make it final. As for familiarity, I am plenty familiar with the concept (though obviously not with the tag description [which does not exist]), but I will also say there is not really any substantive difference between an upgrade and a major upgrade as far as question SEO is concerned; the latter is simply a subset of the former. Likewise a user is probably capable of being an expert in writing upgrade installers (e.g. [upgrade], but less so in specifically being an expert in "major upgrades", in general. – TylerH Sep 09 '19 at 19:40
  • Finally, what constitutes a major upgrade, especially outside WiX, is a matter of opinion. If anything, I'd recommend a separate general tag of [wix-upgrade] or something similar to avoid ambiguity. Note also there is also a [windows-installer] tag that could apply. – TylerH Sep 09 '19 at 19:41
  • @TylerH As I've tried to explain previously, "major upgrade" as used by WiX is defined by Windows Installer. That is why there are questions tagged `major-upgrade` that relate to e.g. InstallShield. Same exact concept, same implications. I expect any general purpose tool for creating Windows Installer installation packages would provide the ability to configure a "major upgrade". – Daniel Pratt Sep 10 '19 at 14:40
  • Let us [continue this discussion in chat](https://chat.stackoverflow.com/rooms/199252/discussion-between-daniel-pratt-and-tylerh). – Daniel Pratt Sep 10 '19 at 14:41

1 Answers1

3

I once wrote a bootstrapper using InstallScript to support a similar story. This was before InstallShield included this functionality and was based on my work that I shared with them.

Basically my code did a lot of work reflecting the instance transforms out of the MSI's Storage and then querying the MSI API to understand which instances were already installed and whether the current MSI represented a Maintenance UI ( same ProductCode and same PackageCode ) or a Major Upgrade Upgrade ( Different ProductCode ) or a Minor Upgrade ( same ProductCode different PackageCode).

You can read about it in more detail at:

Multiple Instance MSI's and InstallShield 12

Here's an explanation of how it works in IS2009+ with screen shots of the bootstrapper UI.

InstallShield 2009 Beta Part I ( Multiple Instances )

Christopher Painter
  • 54,556
  • 6
  • 63
  • 100
  • Thanks for the response, Chris. Alas, from reading those posts, it's still not clear to me how I should be handling the individual cases. Do you agree that authoring a 'major upgrade' into the package is not going to meet my needs if I need to allow multiple instances at different versions? – Daniel Pratt Mar 07 '11 at 18:18
  • You can do major upgrades but you have to remember that each instance has it's own UpgradeCode family and you need to be able to select which instance to perform the upgrade on. In the end you can have X number of instances installed to different directories with different versions and different configuration data. – Christopher Painter Mar 07 '11 at 20:10
  • Hi Chris, what did you mean by "each instance has its own UpgradeCode family"? Wouldn't each instance have the same UpgradeCode, but a different *ProductCode*? – ayang Mar 17 '11 at 20:55
  • If you want each instance to be able to support Major Upgrades, each instance would have to have it's own UpgradeCode. Otherwise a Major Upgrade for one of the instances would uninstall all of the other instances. ( FindRelatedProducts searches by UpgradeCode ) – Christopher Painter Mar 17 '11 at 21:29