PDA

View Full Version : Configuring Upgrade Table of 2 products within 1 ISM project



Octavio Mercado
12-17-2015, 05:39 PM
Hello,

I have 1 ISM project that has 2 different Product Configurations. Product Configuration A uses the Upgrade Code/Product Code that is defined in the General Information.
Product Configuration B defines a different Product Name, and brand new Upgrade Code/Product Code.

I also define Major Upgrades under Media --> Upgrades entries for each: One for A and one for B.
A is defined as Major Upgrade and selected "Products sharing my Upgrade Code".
B is defined as Major Upgrade and selected "Products having another Upgrade Code", where Upgrade code defined in the Product Configuration B is used.

When B is installed, if I attempt to install A, it uninstalls B!. I do not want that. I want A and B to coexist.

I want to achieve the following:
1. A & B to coexist.
2. If later on A2 and B2 are released, A2 should upgrade A, and B2 should upgrade B.

Is this possible to do? Can someone tell me if I am doing this wrong?

Thanks in advance!

DLee65
12-18-2015, 01:37 PM
Have you compared the two MSI outputs to verify that your upgrade table is configured correctly and that the product code / upgrade code is unique for A & B? Based on your description this should already be working because A does not have any connection with B, unless you added 'B''s upgrade code to the Upgrade Table for A.

Octavio Mercado
12-18-2015, 03:53 PM
Yes, I have made sure that both Upgrade Code and Product Code are unique for each product.

I've got 2 entries in the Upgrade table: One for A and one for B.
When B is already installed, running the A installer detects B as a candidate for an upgrade.
UpgradeCode for A is {B7F69531-...} and its ProductCode is {0691458F-...}
UpgradeCode for B is {A350DD7B-...} and its ProductCode is {0B2AA47D-...}

Please take a look at the section of the log:

.InstallShield 12:03:46: Getting records from Upgrade table
InstallShield 12:03:46: UpgradeCode: {B7F69531-1D50-4EFF-B281-AC7C0D08F9C3} MinVersion: 12.5.0 MaxVersion: Language: Attributes: 256
InstallShield 12:03:46: No related products for UpgradeCode {B7F69531-1D50-4EFF-B281-AC7C0D08F9C3} found
InstallShield 12:03:46: UpgradeCode: {A350DD7B-FE1A-422D-904C-A80AA79E1722} MinVersion: 12.0.0 MaxVersion: Language: Attributes: 0
InstallShield 12:03:46: Checking related product {0B2AA47D-60D9-4283-962A-36903DCA9599}
MSI (s) (BC!0C) [12:03:46:511]: PROPERTY CHANGE: Adding IS_MAJOR_UPGRADE property. Its value is 'Yes'.
InstallShield 12:03:46: Bluebeam Vu x64 2016 {0B2AA47D-60D9-4283-962A-36903DCA9599} 0 16.0.3 ***Related***
InstallShield 12:03:46: ALLUSERS of related product {0B2AA47D-60D9-4283-962A-36903DCA9599} is = 1
.
.
.
MSI (s) (BC:74) [12:03:48:960]: Note: 1: 2727 2:
MSI (s) (BC:74) [12:03:48:960]: Doing action: RemoveExistingProducts
Action ended 12:03:48: InstallValidate. Return value 1.
Action start 12:03:48: RemoveExistingProducts.
MSI (s) (BC:08) [12:03:48:960]: Resetting cached policy values
MSI (s) (BC:08) [12:03:48:960]: Machine policy value 'Debug' is 0
MSI (s) (BC:08) [12:03:48:960]: ******* RunEngine:
******* Product: {0B2AA47D-60D9-4283-962A-36903DCA9599}
******* Action:
******* CommandLine: **********
MSI (s) (BC:08) [12:03:48:960]: SRSetRestorePoint skipped for this transaction.

I really do not know why A determines that product B needs to be upgraded.

Any help is greatly appreciated!
Octavio M

DLee65
12-20-2015, 07:30 PM
Ahhh. That is the piece I was misunderstanding. I did not realize you were attempting to upgrade A & B if both exist on the system.

I do not think you can accomplish this by means of your MSI installer.

So at some level, do A & B share some features/components? Do both install to the same directory?

At the end of the day it is all code; I am sure you can develop something to do what you want. I have seen some pretty clever installation gymnastics that I thought could not be done, and should not be done. But others have proven me wrong :)

The only thing I can see that would work is to compile the packages separately, then create some type of wrapper that checks if the product is already installed and if it is a candidate for upgrade. Then present the user with some option boxes to upgrade the selected products. I do not even know if a Suite project can handle this, because you want something that is able to be installed separately, but maintained together is what I suspect. Otherwise you would have had a single product install with different feature activation.

To get back to the mechanics of why this does not work for you, when you add an Upgrade code to product A from Product B, it finds Product B and will attempt to upgrade it with Product A features. It is not running an upgrade for Product B. If paths are unique for each product, I suspect that paths end up getting mangled if you are using properties like INSTALLDIR.

Octavio Mercado
12-21-2015, 10:44 AM
What I am trying to accomplish is to have 1 installer (Basic MSI Project) that has 2 different releases: Product A and Product B.
Both products need to be upgradable, so I have 2 Major Upgrade entries, one for A and one for B.
At install time, Produt A should not care if Product B is installed. A should upgrade A, and B should upgrade B. I do NOT want B to upgrade A, nor A to upgrade B.

To answer your questions; Yes, A and B share features. A is a superset of B. They each install to their own directory. I set the destination depending on Release flags.

I believe the problem I am getting is that when the FindRelatedProducts action executes, both A & B Upgrade Codes get checked because I have the 2 Major Upgrade entries. There is no way to associate Product A to the Major Upgrade entry for A, and Product B to Major Upgrade entry for B.

The only way I see to resolve this issue is to modify the MSIs (post-process), and delete the Major Upgrade entry that is not associated with the product. I really do not want to do this because modifying the database is always risky!

I hope this explains a little bit more what my goal is, and what is the problem I encounter.

Again, any feedback is appreciated.

Octavio

DLee65
12-21-2015, 02:07 PM
Thank you for the clarification.

What happens if in your upgrade table you enter the upgrade code as {00000000-0000-0000-0000-000000000000} (literal text)

At compile time, if my memory is correct, it should replace this placeholder upgrade code with the actual found in your release configuration.

Octavio Mercado
12-21-2015, 04:18 PM
In the Upgrades view, for Product A I select "Products sharing my Upgrade Code". This causes the Upgrade Code to be displayed as {00000000-0000-0000-0000-000000000000}. At build time, this gets populated with the Upgrade Code that is defined in the General Information.
For Product B, I select "Products having another Upgrade Code", and I enter the valid Upgrade Code instead of the {00000000-0000-0000-0000-000000000000}.

The Upgrade Codes for the 2 individual products is fine. The problem is the fact that there are 2 Upgrade items, and both of them are checked with either product.

DLee65
12-22-2015, 10:45 AM
I am not sure then how the upgrade code from both appear in the upgrade table. Are you using the same property for both perhaps and using that property for component / feature conditions?

Based on your description, when you compile A, only the upgrade for A will appear in the upgrade table. It may list different versions for each one but if the version is not correct then the property is not set.

I might poke at this for a bit next week when I have some time, but this does sound strange.

Octavio Mercado
12-22-2015, 12:55 PM
Thanks to Flexera (InstallShield) support team, the problem is solved.

During the build process, what ever gets defined in the Releases\Product Configuration gets populated into the Upgrades table (as long as you select "Products sharing my Upgrade Code" option). There is no need to define a separate Upgrade item for the new product.

Once the MSI is build, he different products have only their respective Upgrade Code in the Upgrade Table.

Thank you for helping resolve this mystery.