3

I am creating an install package using InstallShield Pro X. The upgrade works properly. However, the product manager wants the upgrade to replace all files on an upgrade even if the create date != modify date on the file.

I see that to do this I need to set REINSTALLMODE=vamus rather than vomus. However, I don't see how to tell InstallShield that I want it to use that setting. By default setup.exe always passes vomus to windows installer.

There is a property in the InstallShield project named ReinstallModeText that I changed from omus to amus but that seemed to have no effect.

So, how what do I set in the install project so that when setup.exe detects to run an upgrade it sends REINSTALLMODE=vamus? Thanks.

Update: Tried adding the following to the MSI Command Line value in the Release section:

REINSTALLMODE=vamus

This did not work. Setup.exe didn't set REINSTALL=ALL on the command line what I did this. I added that to the MSI Command line and the upgrade worked as expected. But, not the problem is if it is a NEW install those properties are still being set and the installer fails.

Stein Åsmul
  • 39,960
  • 25
  • 91
  • 164
PilotBob
  • 3,107
  • 7
  • 35
  • 52

4 Answers4

3

Don't set the REINSTALLMODE to amus or vamus (force overwrite files). These settings apply to all components in the MSI, and could hence in theory downgrade system files or at least shared files - this typically involves files included via merge modules. It is normally safe to set REINSTALLMODE to emus (replace files with lower or equal version number). Even this can trigger a file replacement error if you try to overwrite a system protected file on newer versions of Windows featuring Windows Resource Protection (wikipedia) (Windows Server 2008 and Vista onwards). On older Windows versions the file would likely be overwritten and then restored in its right version from the dllcache via the Windows File Protection feature provided that feature had a good day. There was (and is) an associated tool for system file checking: System File Checker.

If you have issues with files that should be replaced even if they have been edited, you can use the RemoveFile table to schedule the file for removal during install (and then it will be reinstalled).

The real solution is to consider the installation folder in %ProgramFiles% as read only, and not have the application save ANY settings or change any files. All config files should go to the user profile or the alluser profile and the application EXE file should be responsible for the copy to the profile locations.

See my answer here.

Community
  • 1
  • 1
Stein Åsmul
  • 39,960
  • 25
  • 91
  • 164
  • The main problem is that QA runs the install created from the build server to test the changes. But, sometimes they will get a DLL from a dev that built it locally. That DLL gets the same version that the new auto-build will get and then when they run the installer they don't get the updated EXE because it is the same version. So the project manager wants it to overwrite all files all the time. main concern is with crystal report files. All are in a single component with a Dynamic File link. I have no idea how that component is treated during an upgrade, since no key file is specified. – PilotBob Jul 04 '09 at 16:49
  • That makes a lot of sense, and is a very common problem. As already stated MSI is a deployment solution, and hence does not always work as expected in testing environments. I sometimes use QA cleanup VBScripts compiled into the test MSI to enforce a clean slate. One question: are you using a minor upgrade or a major upgrade? If you are using a major upgrade, where is your RemoveExistingProduct standard action in the InstallExecuteSequence? – Stein Åsmul Jul 04 '09 at 17:27
3

In investigating this further and testing more options I think the best answer is to modify the product code in addition to the product version and author it as a major upgrade which removes the previous version first and then installs the new files.

The main problem with this is that it takes alot longer for the installer to run. I also think that you can not issue this as a patch, but I could be wrong on that count.

PilotBob
  • 3,107
  • 7
  • 35
  • 52
  • Major Upgrade *almost* always works, just make sure you don't try to use a LOWER versioned keyfile on any component, else you end up with... "MSI (c) (14:B8) [16:32:58:658]: Disallowing installation of component: {1CA051B0-1B70-11D2-9ADD-006097C4E452} since the same component with higher versioned keyfile exists"... ...AND... "MSI (s) (00:70) [16:39:37:283]: Component: foo.exe; Installed: Absent; Request: Local; Action: Null"... (Note Request: Local" but "Action: Null") You're new file won't get installed even though the old one is removed. – joel Jul 13 '10 at 21:34
  • You can get major upgrade patches to work, but then you normally need to put RemoveExistingProducts late in the InstallExecute sequence (otherwise the files that are to be patched are missing when you try to patch them). For safety I also avoid bit-level patching and include "whole files" for files that are to be installed by the patch. – Stein Åsmul Nov 23 '11 at 19:34
  • Finally: for QA usage I really recommend providing a cleanup script or enforce a policy of using clean VMWare machines for testing the setup. The cleanup script is often useful for technical support as well as QA, and is hence recommended to create, but VMWare testing is the most reliable. I like to write the cleanup script in a language that I can compile to executable format so I don't send the cleanup code to the user. Some of them try to extend it on their own, and suddenly they delete all kinds of stuff, and they are there to point fingers at you. – Stein Åsmul Nov 23 '11 at 19:37
1

I don't have IS X handy, but in later versions of InstallShield you would go to "Releases", highlight your release, go to the "Setup.exe" section and there's a field called "MSI Command Line Arguments". There you would indicate any command-line arguments that you want Setup.exe to pass to Windows Installer. E.g. REINSTALLMODE=vamus

William Leara
  • 10,595
  • 4
  • 36
  • 58
  • Ok, I thought this might be the way. But, won't that be passed even for a non-upgrade install. Or does it not matter because REINSTALL isn't set? Or is setup.exe smart enough to only pass it when an upgrade is running? – PilotBob Jun 03 '09 at 18:25
1

You mentioned you used ReinstallModeText with "amus". Have you tried ReinstallModeText equal to "vamus". The "v" causes the installer to run off the source package, not the cached package, and that may be your problem.

William Leara
  • 10,595
  • 4
  • 36
  • 58
  • I know the v is needed. But I assumed because the previous version was omus that this property didn't need the v. – PilotBob Jun 03 '09 at 18:25
  • I could tell from the install log that the command line contained REINSTALLMODE=vomus also, so changing the property seemed to have no effect. – PilotBob Jun 03 '09 at 21:00