Installation upgrade/maint mode issue after Installshield 2010 -> 2012

[cada0310]

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

[cada0310]

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
>>

[MichaelU]

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?

[cada0310]

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

[cada0310]

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

[MichaelU]

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.

[cada0310]

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

[cada0310]

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

[cada0310]

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

[MichaelU]

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.

[cada0310]

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?

[MichaelU]

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.

[cada0310]

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

[cada0310]

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

[cada0310]

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

[MichaelU]

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.