This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- Revenera Community
- :
- InstallShield
- :
- InstallShield Forum
- :
- Re: Failure with minor updates
Subscribe
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Subscribe
- Mute
- Printer Friendly Page
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎May 21, 2012
01:06 PM
Failure with minor updates
We use minor update mode to update the majority of our programs, making the project version number match the EXE version number.
I had a project in IS2012 that was converted to IS2012 Spring. Prior to conversion the version of the primary exe and project was 24.03.09. We released an update to 24.03.10 and did this using the IS2012 Spring, changing the version number of the project and primary exe.
We're getting support reports that the 24.03.10 update did not update the primary exe.
On a test machine, I uninstalled the product completely, ran the .09 install, then ran the .10 update and confirmed the primary exe is not being replaced. When I delete the primary exe from the program files folder and run the .10 installer in repair mode, the exe then is written with the correct .10 version.
I've attached the two MSI logs.
Lance
I had a project in IS2012 that was converted to IS2012 Spring. Prior to conversion the version of the primary exe and project was 24.03.09. We released an update to 24.03.10 and did this using the IS2012 Spring, changing the version number of the project and primary exe.
We're getting support reports that the 24.03.10 update did not update the primary exe.
On a test machine, I uninstalled the product completely, ran the .09 install, then ran the .10 update and confirmed the primary exe is not being replaced. When I delete the primary exe from the program files folder and run the .10 installer in repair mode, the exe then is written with the correct .10 version.
I've attached the two MSI logs.
Lance
(2) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎May 25, 2012
12:19 PM
I created a case - SIOC-000126851 - reporting this issue. I still haven't heard an answer back as to the cause, but will post any answers.
If anyone has any suggestions, they are welcomed.
If anyone has any suggestions, they are welcomed.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jun 01, 2012
05:03 PM
It looks like possibly I've found the issue. I had to call back after not hearing word for a couple weeks and talked with an engineer.
The log complains a component was removed compared to the original shipping.
After comparing MSI's from the current shipping and older MSI's, I think I found the culprit.
After installing IS2012 Spring when first released, I found a problem regarding IS failing because it couldn't sign the Software ID Tags. I had tried disabling the tags and it worked, re-enabled and it failed. Later found out the installer omits the tool used to sign the Software ID tags and resolution was to copy the 2012 tool to the 2012 spring directory to resolve.
What happens, though, is when you disable and re-enable the Software ID's, new guids are formed for components for the ISO19770_LocalTag and ISO19770_SystemTag. I've manually reassigned the guids to match the earlier installs and will see if this resolves the issue.
My question / suggestion would be: Store the guids used for the components so disable/re-enabling keeps the same guid unless you manually change it or save to a new project that is designated to have a new project guid.
The log complains a component was removed compared to the original shipping.
After comparing MSI's from the current shipping and older MSI's, I think I found the culprit.
After installing IS2012 Spring when first released, I found a problem regarding IS failing because it couldn't sign the Software ID Tags. I had tried disabling the tags and it worked, re-enabled and it failed. Later found out the installer omits the tool used to sign the Software ID tags and resolution was to copy the 2012 tool to the 2012 spring directory to resolve.
What happens, though, is when you disable and re-enable the Software ID's, new guids are formed for components for the ISO19770_LocalTag and ISO19770_SystemTag. I've manually reassigned the guids to match the earlier installs and will see if this resolves the issue.
My question / suggestion would be: Store the guids used for the components so disable/re-enabling keeps the same guid unless you manually change it or save to a new project that is designated to have a new project guid.
