Product version not updated in the ini file

[CChong]

Here is what I found,
Let's call A a first generation of an installer for the product X and B the second.
The first version of A do not contain InstallShield Update Service, so it just install X (revision 1.0). A second version of A update X (revision 1.2) and install InstallShield Update Service. No problem so far. We can have a third version of A that update X (revision 1.3) and update the ini file to reflect this new revision.
Now we use the new generation of installer B. It update X (revision 2.0) but he will not update the ini file so IsntallShield Update Service still show revision 1.3 :confused:
If you install update X again with a B installer to go to revision 2.1 InstallShield Update Service still show revision 1.3 :confused:
The weird part is that if you first install X with B (revision 2.0) the ini file reflect the correct version and upgrade to 2.1 works also.
So I'm confuse there is no difference in the code between A and B.
Am I missing something, or is there a bug in InstallShield Update Service.

I'm using InstallShield Professional 6.31 and InstallShield Update Object version 1.20 for both installer A and B
The code is the same and really simple as describe in the documentation:
In OnBegin:

// register to update service
set oObject = GetObject("InstallShield Update Service");
oObject.ProductCode = PRODUCT_GUID; //GUID of X
oObject.ProductVersion = szVersion; // Version of X

If you have any input or solution about this problem please let me know.

Thanks
-- Renaud

[Chris_Woerner]

Sorry about the problem.

As I understand from you posting, with the first version of the installation, the entire process works in going from version 1.0 to 1.2 to 1.3. So that's good. It also works if you start with version 2.0 and update to 2.1. So that's also good.

The problem comes when converting from your installer A to installer B. The upgrade from version 1.3 to version 2.0 doesn't work properly. The version is not getting updated in the INI file.

So lets focus on that....

1. Do both generations of the installer (A and B) use the same product code? Or are they different product codes?

2. Try installing version 1.3. Next, run the update. Either put a save off (or display) the values of PRODUCT_GUID and szVersion to make sure they contain the correct values.

Let me know the results....

[CChong]

Originally posted by Chris Woerner

1. Do both generations of the installer (A and B) use the same product code? Or are they different product codes?

What do you mean by product code? Are you talking about the GUID of the application? If it's the case, yes they are the same.
I you are talking about the code of the installer they are pretty similar, and the code related to InstallShield Update Service is exactly the same.

2. Try installing version 1.3. Next, run the update. Either put a save off (or display) the values of PRODUCT_GUID and szVersion to make sure they contain the correct values.

Let me know the results....

Yes I already done this test and both values are correct (PRODUCT_GUID and szVersion)

One more thing, if I you go from 1.3 to 2.1, it doesn't work either.
So the problem is really going from the installer A to B.

Thanks
-- Renaud

[Chris_Woerner]

By product code, I mean the product code found in the Installer. So your product codes are different. That isn't an issue - just something to note as we debug this issue....

Q: If I have version 1.3 installed and I want to go to version 2.1, do you have an update install?

Q: If I install version 2.1 from the start is this a different install from the update or is it the same install?

[CChong]

Q: If I have version 1.3 installed and I want to go to version 2.1, do you have an update install?

Yes this is an update install, basically we overwrite nearly every thing. In the installer we do detect if a previous install is present or not.

Q: If I install version 2.1 from the start is this a different install from the update or is it the same install?

It is the same install, the result of an upgrade to 2.1 or a fresh 2.1 install are equivalent except for the Update Service problem 😉

[CChong]

Hello Renaud,
Could you provide a copy of your project or .rul file so that I could take examine it?
Sincerely,
Leykun M.
InstallShield

[CChong]

I'm trying to understand how it works, to find the solution or locate where is the problem before sending code or projects that include a lots of code and files...

So my questions are:
How come .rul files can make any difference as long as we register the InstallShield Object in the OnBegin (I'm this part of the code is executed)?
I would like to know when the ini file is supposed to be updated.
Is there a way to force this update in the code?

Thank you.

-- Renaud

[Chris_Woerner]

Adding this code to your setup sets properties for the object. When the object runs, it calls the ISUS Agent to register the version in the INI file. It is actually a very simple and usually problem free task.

// register to update service
set oObject = GetObject("InstallShield Update Service");
oObject.ProductCode = PRODUCT_GUID; //GUID of X
oObject.ProductVersion = szVersion; // Version of X


The scenario you describe should never happen. One setup should always set the same value in the INI file.

The things that we would look for is how the value of ProductVersion is being set. Is there some kind of conditional logic that could affect that value? Or is the object itself not being invoked - thus the update to the INI file is not being done? That later is more likely the reason.

BTW - If you want to force the register to happen, you can call the ISUS Agent at the end of your install via the commandline interface or from your application via the commandline interface or via the COM interface. The call takes two parameters, product code and version.

Agent -r{C4091E43-4FC0-11D5-8C6C-00104B9747FA},1.2.3

Examples are the in the help. Look up commandline options.

[CChong]

Originally posted by Chris Woerner
When the object runs, it calls the ISUS Agent to register the version in the INI file. It is actually a very simple and usually problem free task.

When this object "runs"? I went step by step during the install and all the values (oObject.ProductCode and oObject.ProductVersion) are set with the right value.
Any way my understanding is that if the szVersion is not the right one the ini file pointed by the GUID application will be modified with the ProductVersion set in the oObject. In my case it is not the case the file is not modified at all.

The things that we would look for is how the value of ProductVersion is being set. Is there some kind of conditional logic that could affect that value? Or is the object itself not being invoked - thus the update to the INI file is not being done? That later is more likely the reason.

No, there is no condition in my code and like I said I checked that it was called with the right values debugging step by step.

By running the installer step by step, I notice that after setting the oObject the modification is not done right away to the ini file. It's done after copying all the files.

Here is some more question to try to understand how it work and maybe found were the problem is:

When the ini file is being modified? Is it during a specific InstallShield event?
Is there some conditions in the ISUS object that will prevent the modification of the ini file? Is it checking for some registry or installed files that can be missing in my case?

I notice by creating a dummy installer that if in OnMainUIBefore we do not have a call to ComponentReinstall() if we want to run again the installer, then the ini file is not modified. It's not the case in my application installer but maybe someting similar exist and prevent this to happen in my case...

BTW - If you want to force the register to happen, you can call the ISUS Agent at the end of your install via the commandline interface or from your application via the commandline interface or via the COM interface. The call takes two parameters, product code and version.

Agent -r{C4091E43-4FC0-11D5-8C6C-00104B9747FA},1.2.3

Examples are the in the help. Look up commandline options.

Thanks for the hint, that will be my last solution if I do not find what is wrong. But I'm trying to avoid this last chance solution

Thanks

-- Renaud

[Chris_Woerner]

As you probably know, object code is merged into your script code during the runtime. The object code that calls the ISUS Agent to update the INI file is called in the OnMoved event. There is no conditional logic in the object.

Can you confirm that the component that object is linked to is being selected? Does that component contain file groups that also have other updates?

Also, can you reproduce the problem with a simple project?

[CChong]

Originally posted by Chris Woerner
As you probably know, object code is merged into your script code during the runtime. The object code that calls the ISUS Agent to update the INI file is called in the OnMoved event. There is no conditional logic in the object.

Is there a way to trace this code?

Can you confirm that the component that object is linked to is being selected? Does that component contain file groups that also have other updates?

Yes I just add some code to check that and it definitely is selected.
There is just this object in this particular component. But again the weird thing is that the UpdateService is not installed just if a particular installer is previously run.

Run A -> C -> C ... (A doesn't have ISUS, C does but doesn't install it for unknown reason.)
Run B -> C -> C (B install ISUS, C update it both time)

Also, can you reproduce the problem with a simple project?

I'm working on it, but it's like knowing what the problem is and isolate it... And I don't know what the problem is... :confused:

Thanks
-- Renaud

[Chris_Woerner]

I still believe that the ISUS object is not being invoked for some reason. Something to try that may give us insight into the problem....

You said the ISUS object is in its own component. Try adding a new component to your 2.0 setup and adding the ISUS object to the new component. Now remove the ISUS from the old component - but don't remove it.

Just to verify, you are calling ComponentReinstall?

[CChong]

I think I have found the problem, but I do not understand the cause. At the end of OnMaintUIBefore I add a call to SdComponentDialog to check which components are selected (to see if updateService is selected). The updateService component is selected but the size is 0. If I un-check and check again this component in the dialogue box now it show a size and it's going to be installed and every thing work fine.

So is there a difference between calling ComponentSelectItem or checking the component via SdComponentDialog? Calling ComponentReinstall affect also the component selection, do you see anything I can do to obtain the same result as calling SdComponentDialog and un-checking and re-checking those components that show a size 0k?

Thanks
-- Renaud

[diazobe]

Hello Renaud,

When the setup goes into Maintenance mode, it scans the log file to determine what components are currently installed. The setup will not install components that were previously installed, unless you specify that it should, by calling ComponentReinstall.

I have enclosed a sample that reproduces the main issue (It is not specific to ISUS). The sample has a component called 'A' that installs a file called a.txt to 'C:\Program Files\IS\Sample ISUS Maint' ftp://ftp.installshield.com/outgoing/Obed/ISUSSmpl.zip


Try the following:
1) Build and install the enclosed sample
2) After installing, go to: 'C:\Program Files\IS\Sample ISUS Maint' and delete the file a.txt
3) Run the setup again (it will go into maintenance mode' and select modify. (notice that component 'A' is going to be selected with a size of 0 bytes)
4) Finish the installation and notice that a.txt is still missing from: 'C:\Program Files\IS\Sample ISUS Maint'

That is the default behavior in ISPro6.x

Now, go to the code and remove the comments in front of a call to ComponentReinstall that I included in OnMaintUIBefore.

Repeat the steps from above and notice that a.txt is now being restored.

The issue that you are experiencing with ISUS is that ISPro6 thinks that the Component that includes the Update Service Object is already installed, so it does not execute any of the Update Service events inside the object.

Please try adding a call to ComponentReinstall after you do component selections in your update setup, and let me know how it goes.

Regards,

-Obed

[CChong]

Originally posted by diazobe
Hello Renaud,
The issue that you are experiencing with ISUS is that ISPro6 thinks that the Component that includes the Update Service Object is already installed, so it does not execute any of the Update Service events inside the object.

Please try adding a call to ComponentReinstall after you do component selections in your update setup, and let me know how it goes.

I already call ComponentReinstall and I see the same behavior as described when ComponentReinstall is not called.
You are talking about a log file that is scan to determine which components are installed. My problem come with two different installer (see previous posts). So I was looking at the description of the components and I notice that there is a GUID for each components in Default.cdf. If they are different for the same components in different installer what is going to happen? I'm trying to manualy change those GUID to match the first installer to see if that fix the problem... I'll let you know the result. Any other ideas?

Thanks
-- Renaud

[CChong]

Okay that was the components GUID that were different between the two generations of installer. Changing the component GUID in the new installer with the old one fix the problem. So now I need to find a way to overwrite the old components with the old guid with the new one, because I cannot change the GUID in the new installer like I did in my test. So I need to find a way to avoid this problem... any sugestions?

Thank you all for your help!

-- Renaud

[CChong]

Still have some trouble with this!
I succeed to create two small installer that reproduce the problem.
Launch Inst1 then Inst2 you will see that even if I call ComponentReinstall() the update service files are not installed.
But if you unselect and reselect it, then every thing works fine
Let me know what you think...

Once again thanks for your help

-- Renaud

[diazobe]

Hello Renaud,

Let's cheat 🙂

Remember how you could not get the component to Install when you called ComponentSelectItem? The reason is that internally there were 2 components (Old GUID and New GUID) with the same name, so Component Reinstall would choose the first component of the two (old GUID).

This is what you need to do: (assuming that the component in the original installation was called MyComponent)

1) Take 'MyComponent' (the one with the new GUID) and rename it to 'MyComponent_New'
2) Add a line in your script that would call ComponentSelectItem to select the new Component. (ComponentSelectItem(MEDIA,"MyComponent_New", TRUE); )
3) Run the setup and see if it works.

After you get that to work, all you have to do is change the Display Name for the 'MyComponent_New' component to be MyComponent.

This may be a little weird, but if you think about it... a component with a new GUID is a new Component, so it should have a new name.
Please let me know how it goes.

Regards,

-Obed

[CChong]

Originally posted by diazobe
Hello Renaud,
1) Take 'MyComponent' (the one with the new GUID) and rename it to 'MyComponent_New'
2) Add a line in your script that would call ComponentSelectItem to select the new Component. (ComponentSelectItem(MEDIA,"MyComponent_New", TRUE); )
3) Run the setup and see if it works.

This doesn't work 😞
And I knew it will not work. If you look at the two installers I posted previously. The first one got one component MainApp and the second one MainApp and UpdateService. My goal is to install also the UpdateService component. I can only achieve this goal by unselecting and selecting again the component under the dialog box.

Can you explain me what is wrong in those two installer and how I can't fix the problem? I have a feeling that the problem come to the fact that there is no FileGroups attached to this UpdateService component.

Thanks
-- Renaud

[diazobe]

Hello Renaud,

Attached is my own working sample that mimics your own.
Please give it a try, and let me know how it goes.

Regards,

-Obed

[CChong]

You example works 🙂
Now I try to understand why, because I try to modify my version posted earlier (Inst2) and I can't make it work. :confused:
I tried to rename both components and select them with ComponentSelectItem... but nothing change.
What is the trick?

Thanks
-- Renaud