cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Eric_Vanlaeken
Level 4

minor upgrade msi in new version of suite removes suite

Hi team,

I made a a version 1 of a suite with one msi package version 1 and a version 2 of the same suite (same guid) with an minor upgrade of msi as version 2.
When I install the version 1 of the suite I see 2 entries in the ARP and both have version 1 (the suite and the msi).
So far so good.
When I now run the version 2 of the suite, the msi package is updated to version 2 but the version 2 of the suite is not installed. In stead the suite is removed (only one entry of the msi in ARP).
Anyone an idea what is going on here. One should suppose that the suite too should be updated to version 2.

Thanks in advance of all the help I can get.
ERic
Labels (1)
0 Kudos
5 Replies
MichaelU
Level 12 Flexeran
Level 12 Flexeran

That sounds to me most likely that the mode condition (built from the detect condition of your primary packages) is indicating that the suite is no longer installed. Do you have a custom detect condition, or are you using the automatic condition derived for msi packages? There should be some indication confirming or denying this theory in the /debuglog output.

Also have you been referencing the recently posted white paper on upgrading packages in a suite (see the sticky: Managing the Life Cycle of a Suite/Advanced UI Installation)? While the case you describe isn't particularly intricate, the paper might help to confirm you're headed the right direction.
0 Kudos
Eric_Vanlaeken
Level 4

Hi Michael,

Thanks for your quick response.
In fact, in the second version of the suite there was no "detection condition" specified for the msi package. I've changed this to detect if a msi package with same product code is installed (minor update = only product version and package code change) but now with an update of sute V2 on an installed suite 1 it updates the suite version but not the msi package. So, I have now a suite version 2 with msi package version 1.
Can you explain in short what the difference is between the "detection condition" and the "eligibility condition"?
I must remark that with suite V2 I can do a clean install too although the "detection condition" for the msi package is defined now. I'm getting V2 of the suite with V2 of the msi.

Thanks for your help,
Greetings,
Eric
0 Kudos
MichaelU
Level 12 Flexeran
Level 12 Flexeran

If you're using an "MSI Package" in the suite (raw .msi, no .exe wrapper, etc.) you shouldn't need to populate the detection condition here. We will automatically create a detection condition based on the metadata of the .msi file included in the build. Thus the "no detection condition" case should be fine, even preferred. If instead you are using an "EXE package", the automatic behavior goes out the window, and you need to provide useful detection conditions yourself.

The difference between detection conditions and eligibility conditions is what question they answer. A detection condition answers whether the package is present on the machine. The eligibility condition answers whether the package should be processed on that machine. So typical detection conditions will look for a registry key, a registered MSI product, or some other artifact put in place by an installation and removed at uninstallation. By the same token, typical eligibility conditions will look for things this suite will not change, such as a requirement on a version of Windows, or 32 vs 64-bit systems, dependencies of the package that are not included in the package (such as the .NET framework, if you don't include it as another package), or even later versions of the package (to avoid downgrades).

With the detection code you say you've added, I see two possible behaviors. If the MSI's package is "primary" and you haven't changed the Suite version, running the new suite will run in maintenance mode; this mode will not typically upgrade packages. If the package is "dependency" or if you have changed the Suite version, the suite should run as a first-time installation; however since the package is detected, it will not be installed. So for either scenario, I think your detection condition is too broad. (We typically check ProductVersion or PackageCode.)

I recommend trying to isolate what is happening by checking out the /debuglog, and reading the white paper and some of the blog articles on suites such as Troubleshooting Issues by Logging a Suite Installation and Defining Conditions for a Suite Installation.
0 Kudos
Eric_Vanlaeken
Level 4

Hi Michael,

Thank you for explanation about the detect and the eligibility conditions. I'm getting the message on that.

The fact is now that if I don't specify a detect condition there is a implicit detect condition on the Product Code and the Package Code (seen in the logfile). And not on the Productversion or the Package Code as you presume in your message. Well, it that case, if I run the setup version 2 on a clean machine (first installation) then after the msi package is installed (primary and only package) the detection returns true (for the check on the product code and the package code). This is correct. The suite and the msi are correctly installed and can be seen in the ARP.

However, if I first install the version 1 of the suite (that installs version 1 of the msi) and after that installs version 2 of the suite (that should upgrade the msi to version 2), the detect condition in the log after the msi is correctly updated retuns false (for the check on the product code and the adapted package code). And the result is that the suite unregisters itself and the entry for the suite in the ARP is gone (meaning that the suite is not registred).

I have to deliver a first version of the product soon but I should be sure that the update mechanism works properly.

As a remark I must say that my suite installer is only a tiny one that gets its msi's through a http:// url. I don't know if caching or so has something to do with this problem. I'm stuck...:confused:

By the way: I've read every link and white paper that you mentioned in your previous messages.

If you have more tips, please let me know.

Greetings
Eric
0 Kudos
Eric_Vanlaeken
Level 4

Hello Michael,

I found the error. You shouldn't search for a solution anymore.
The problem was that I've added 2 custom actions that cleared 2 properties. The first one cleared the property REINSTALL and the second one the property REINSTALLMODE. These CA's should run if the property "Installed" was not set (condition of the CA should be "Not Installed"). This way, you could always startup the installer with the additional properties set, no matter if this is a first install or an update of a previous install. The command should always be "msiexex /i"xxxx.msi" REINSTALL=ALL REINSTALLMODE=vomus". This is easier for the customer.
The problem was however that I didn't fill in the condition "Not Installed" for every CA. The net result was that when I started the version 2 of the Suite on top of an allready installed version 1 that the installation of the msi was not updated to version 2 but stayed at version 1 allthough in the ARP applet the version number was updated. In fact, after the installation the package code of the second version was not detected by the version 2 of the Suite (the packagecode of the first version was still there) and it removed itself from the machine because the suite could detect that the second version was installed.
So, I fixed conditions for the 2 CA's and it works now.

Thank you for your help,
Eric
0 Kudos