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
- :
- Installation upgrade/maint mode issue after Installshield 2010 -> 2012
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
‎Nov 28, 2011
10:47 AM
Installation upgrade/maint mode issue after Installshield 2010 -> 2012
Hi all,
We've been working with IS 2010 Pro for quite some time. We do our new builds, build the installations, etc. When you run the new installation on a server that already has the software installed, you get the nice "going to upgrade from version 1 to version 2..." dialog box. Been working fine for years.
I've done the following, and the maint/mode upgrade is broken - it fails to upgrade any files in the installation folder (but it does other tasks, like running our SQL scripts):
- Upgraded to 2012 Premier
- Added a language
- Rebuilt our installation
Fresh installation works great, puts the right files down.
Any tips while we troubleshoot?
Thanks,
Chris
We've been working with IS 2010 Pro for quite some time. We do our new builds, build the installations, etc. When you run the new installation on a server that already has the software installed, you get the nice "going to upgrade from version 1 to version 2..." dialog box. Been working fine for years.
I've done the following, and the maint/mode upgrade is broken - it fails to upgrade any files in the installation folder (but it does other tasks, like running our SQL scripts):
- Upgraded to 2012 Premier
- Added a language
- Rebuilt our installation
Fresh installation works great, puts the right files down.
Any tips while we troubleshoot?
Thanks,
Chris
(15) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Nov 28, 2011
11:12 AM
A little more information from our logs; never saw this error before...didn't happen with IS 2010 as far as we can tell.
Nothing actually comes up during the installation - it just runs along happily, and doesn't upgrade any of our executables to the new version.
<<
MSI (c) (C0:48) [11:54:14:737]: PROPERTY CHANGE: Adding PackagecodeChanging property. Its value is '1'.
Another version of this product is already installed. Installation of this version cannot continue. To configure or remove the existing version of this product, use Add/Remove Programs on the Control Panel.
{44876C0F-0658-402B-866E-E7B97CB1B41E}
MSI (c) (C0:48) [11:54:14:740]: Note: 1: 1729
MSI (c) (C0:48) [11:54:14:741]: Product: DME Nuance Management Server and Console Installation -- Configuration failed.
MSI (c) (C0:48) [11:54:14:742]: Windows Installer reconfigured the product. Product Name: DME Nuance Management Server and Console Installation. Product Version: 2.0.77. Product Language: 1033. Reconfiguration success or error status: 1638.
=== Verbose logging stopped: 11/28/2011 11:54:14 ===
=== Verbose logging started: 11/28/2011 11:54:14 Build type: SHIP UNICODE 4.05.6002.00 Calling process: C:\Nuance Management Server and Console Installation.exe ===
MSI (c) (C0:48) [11:54:14:757]: Cloaking enabled.
MSI (c) (C0:48) [11:54:14:757]: Attempting to enable all disabled privileges before calling Install on Server
MSI (c) (C0:48) [11:54:14:757]: End dialog not enabled
>>
Nothing actually comes up during the installation - it just runs along happily, and doesn't upgrade any of our executables to the new version.
<<
MSI (c) (C0:48) [11:54:14:737]: PROPERTY CHANGE: Adding PackagecodeChanging property. Its value is '1'.
Another version of this product is already installed. Installation of this version cannot continue. To configure or remove the existing version of this product, use Add/Remove Programs on the Control Panel.
{44876C0F-0658-402B-866E-E7B97CB1B41E}
MSI (c) (C0:48) [11:54:14:740]: Note: 1: 1729
MSI (c) (C0:48) [11:54:14:741]: Product: DME Nuance Management Server and Console Installation -- Configuration failed.
MSI (c) (C0:48) [11:54:14:742]: Windows Installer reconfigured the product. Product Name: DME Nuance Management Server and Console Installation. Product Version: 2.0.77. Product Language: 1033. Reconfiguration success or error status: 1638.
=== Verbose logging stopped: 11/28/2011 11:54:14 ===
=== Verbose logging started: 11/28/2011 11:54:14 Build type: SHIP UNICODE 4.05.6002.00 Calling process: C:\Nuance Management Server and Console Installation.exe ===
MSI (c) (C0:48) [11:54:14:757]: Cloaking enabled.
MSI (c) (C0:48) [11:54:14:757]: Attempting to enable all disabled privileges before calling Install on Server
MSI (c) (C0:48) [11:54:14:757]: End dialog not enabled
>>
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Nov 28, 2011
12:24 PM
Have you changed your procedure here? It sounds like you're trying to run a small or minor update without the necessary configuration. So did you change your ProductVersion (it's a small update if you didn't); or your ProductCode (it's a major upgrade if you did). Are you launching from a .msi or from the setup.exe? If from a .msi, are you passing REINSTALLMODE and REINSTALL properties to the .msi?
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Nov 28, 2011
12:40 PM
Hi Michael,
Thanks for your prompt reply. Our procedure hasn't changed other than what was described in changing Installshield versions as far as I can tell - I'm the one that's been working on upgrading, and those are the only steps I've taken (consciously 🙂 ).
Our build process is all batch driven and on an isolated build machine - we simply upgraded the builder to use the new IS2012 exes. When the upgrade starts up, it gives the dialog saying that it's going to upgrade from one version to the other (and it has the right source and target version numbers), so it appears to know what it needs to do...
All we update is the ProductVersion with our version number in every build. In this case, we are launching the installation from the setup.exe.
Chris
Thanks for your prompt reply. Our procedure hasn't changed other than what was described in changing Installshield versions as far as I can tell - I'm the one that's been working on upgrading, and those are the only steps I've taken (consciously 🙂 ).
Our build process is all batch driven and on an isolated build machine - we simply upgraded the builder to use the new IS2012 exes. When the upgrade starts up, it gives the dialog saying that it's going to upgrade from one version to the other (and it has the right source and target version numbers), so it appears to know what it needs to do...
All we update is the ProductVersion with our version number in every build. In this case, we are launching the installation from the setup.exe.
Chris
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Nov 28, 2011
02:08 PM
An additional tidbit.
I just did two builds of our stuff using IS 2012, and the upgrade from one version to the other actually worked.
What looks like is not working is the installations we have using IS 2010 upgrading to the installations built with IS 2012.
Chris
I just did two builds of our stuff using IS 2012, and the upgrade from one version to the other actually worked.
What looks like is not working is the installations we have using IS 2010 upgrading to the installations built with IS 2012.
Chris
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Nov 29, 2011
01:33 PM
As a sanity check, is your ProductVersion in the correct format (255.255.65535.* max), and changing within the first three parts? Since you're running from our setup.exe, it should detect and run a minor upgrade correctly...if it's actually a minor upgrade.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Nov 29, 2011
01:40 PM
Hi Michael,
Yes, as an example, our version numbers are:
1.0.1.895 (old one built with IS2010)
2.0.0.87 (new one built with IS2012)
2.0.0.87 upgrades no problem to 2.0.0.89 for example (both built with IS2012). However, 1.0.1.895 will not upgrade to 2.0.087.
Thanks,
Chris
Yes, as an example, our version numbers are:
1.0.1.895 (old one built with IS2010)
2.0.0.87 (new one built with IS2012)
2.0.0.87 upgrades no problem to 2.0.0.89 for example (both built with IS2012). However, 1.0.1.895 will not upgrade to 2.0.087.
Thanks,
Chris
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Nov 29, 2011
02:12 PM
Just one more note; up until about build 2.0.0.70, we were using IS2010, and that upgraded from 1.0.1.895 without issues.
Thanks,
Chris
Thanks,
Chris
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Nov 30, 2011
08:28 AM
Did a little more testing, and looked in the registry.
In the CurrentVersion\Uninstall area for our product, the "DisplayVersion" is 1.1.882 (old), and the version I built with IS2012 this morning is 2.1.1000. I bumped up all of the version number elements to make sure that wasn't part of the issue.
Still didn't work. The installation knew it was upgrading, did stuff, but wouldn't overwrite any of the exe/dll files that have version numbers associated with them.
The old files themselves have a File/Product version of 1.0.1.882 (which is their assembly version).
Again, this all works like a champ if we're just using IS2010 - something seems different between how things are handled in 2010 vs 2012...as far as I can tell.
Would log files help out at all to figure out why the components aren't getting updated?
Thanks,
Chris
In the CurrentVersion\Uninstall area for our product, the "DisplayVersion" is 1.1.882 (old), and the version I built with IS2012 this morning is 2.1.1000. I bumped up all of the version number elements to make sure that wasn't part of the issue.
Still didn't work. The installation knew it was upgrading, did stuff, but wouldn't overwrite any of the exe/dll files that have version numbers associated with them.
The old files themselves have a File/Product version of 1.0.1.882 (which is their assembly version).
Again, this all works like a champ if we're just using IS2010 - something seems different between how things are handled in 2010 vs 2012...as far as I can tell.
Would log files help out at all to figure out why the components aren't getting updated?
Thanks,
Chris
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Nov 30, 2011
09:14 AM
Most of this is handled by Windows Installer itself. It might be somewhat enlightening to build the update with each and use InstallShield MSI Diff to compare the resulting .msi files either between base and new, or between the outputs of InstallShield 2010 and 2012. The latter will of course have some differences that are not relevant, but it might let you zero in on what shouldn't be happening.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Nov 30, 2011
09:20 AM
Thanks Michael. This particular installation only builds a SETUP.EXE...does that tool work with those? Or will I have to build an MSI as well to use it?
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Nov 30, 2011
09:24 AM
It does not work with it directly. You can perform an administrative install by running setup.exe /a and get the .msi file from the directory you choose.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Nov 30, 2011
11:32 AM
So, more weirdness.
I tagged one of our dll components as "always overwrite" and even that didn't do anything. I also checked the component and made sure its component code was the same with the old installation and the new, and it is the same.
What would prevent something tagged as always overwrite not getting put down?
I compare this to something that did actually get updated on the disk, and here's what I see in the log.
Our DLL which didn't get updated (one of many):
-----------------------------------------------
MSI (s) (A8:14) [11:59:59:030]: Component: eScriptionDataConnector.v1.dll; Installed: Local; Request: Null; Action: Null
Some SQL scripts which did get updated:
---------------------------------------
MSI (s) (A8:14) [11:59:59:028]: Component: SQL_Scripts; Installed: Local; Request: Local; Action: Local
MSI (s) (A8:14) [11:59:59:028]: Component: __DatabaseCreation.sql_SQLComponent; Installed: Local; Request: Local; Action: Local
MSI (s) (A8:14) [11:59:59:028]: Component: __DefaultDataPopulation.sql_SQLComponent; Installed: Local; Request: Local; Action: Local
MSI (s) (A8:14) [11:59:59:028]: Component: __SchemaUpdates.sql_SQLComponent; Installed: Local; Request: Local; Action: Local
MSI (s) (A8:14) [11:59:59:028]: Component: __TableCreation.sql_SQLComponent; Installed: Local; Request: Local; Action: Local
MSI (s) (A8:14) [11:59:59:028]: Component: sqlscript.sql_SQLComponent; Installed: Local; Request: Local; Action: Local
All our dlls and exes have the Request and Action as "null" for some reason?
Chris
I tagged one of our dll components as "always overwrite" and even that didn't do anything. I also checked the component and made sure its component code was the same with the old installation and the new, and it is the same.
What would prevent something tagged as always overwrite not getting put down?
I compare this to something that did actually get updated on the disk, and here's what I see in the log.
Our DLL which didn't get updated (one of many):
-----------------------------------------------
MSI (s) (A8:14) [11:59:59:030]: Component: eScriptionDataConnector.v1.dll; Installed: Local; Request: Null; Action: Null
Some SQL scripts which did get updated:
---------------------------------------
MSI (s) (A8:14) [11:59:59:028]: Component: SQL_Scripts; Installed: Local; Request: Local; Action: Local
MSI (s) (A8:14) [11:59:59:028]: Component: __DatabaseCreation.sql_SQLComponent; Installed: Local; Request: Local; Action: Local
MSI (s) (A8:14) [11:59:59:028]: Component: __DefaultDataPopulation.sql_SQLComponent; Installed: Local; Request: Local; Action: Local
MSI (s) (A8:14) [11:59:59:028]: Component: __SchemaUpdates.sql_SQLComponent; Installed: Local; Request: Local; Action: Local
MSI (s) (A8:14) [11:59:59:028]: Component: __TableCreation.sql_SQLComponent; Installed: Local; Request: Local; Action: Local
MSI (s) (A8:14) [11:59:59:028]: Component: sqlscript.sql_SQLComponent; Installed: Local; Request: Local; Action: Local
All our dlls and exes have the Request and Action as "null" for some reason?
Chris
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Nov 30, 2011
01:54 PM
Michael,
I think we've discovered the root of the problem by using the msi diff tool; when we upgraded to 2012, there was a merge module that IS2012 couldn't locate.
When I re-browsed to the merge module, it appears IS2012 removed all of the components associated with it, and re-added them. Until now, I didn't realize that I had re-browsed to a different version of the merge module.
We're building now with the right version added, and will let you know the results.
Chris
I think we've discovered the root of the problem by using the msi diff tool; when we upgraded to 2012, there was a merge module that IS2012 couldn't locate.
When I re-browsed to the merge module, it appears IS2012 removed all of the components associated with it, and re-added them. Until now, I didn't realize that I had re-browsed to a different version of the merge module.
We're building now with the right version added, and will let you know the results.
Chris
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Nov 30, 2011
03:54 PM
Yep, that was it.
Thanks for your help, Michael, and especially the tip on the MSI diff - that'll come in handy in the future for sure.
Thanks,
Chris
Thanks for your help, Michael, and especially the tip on the MSI diff - that'll come in handy in the future for sure.
Thanks,
Chris
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Dec 01, 2011
12:04 PM
Glad to hear. On your last symptom, I was going to suggest checking for SELMGR errors, indicative of an invalid minor upgrade. Minor upgrade validation can also help catch those. And a missing merge module would almost definitely cause such errors.