I created an MSI Install with InstallShield 2014. Everything is fine and dandy. This may be outside of the scope of InstallShield at this point, but I thought I would ask here anyway.
Essentially I'm developing an update system for the product that would read a manifest file on the web and update files in the install as needed. EXE versions would change and such.
I'm wondering how this would affect an MSI installer if the original exe that was installed is no longer the current exe that's installed despite the filename and location remaining the same.
The full answer to this depends largely on which scenarios you care about supporting. From a Windows Installer perspective, you should be issuing some form of upgrade so that it can track the currently known version of the EXE. However, so long as things are versioned correctly, the most likely problem scenario is the updated file going missing and repair or auto-repair replacing it with the last version it knows about. Depending on the topology of your program, you may now have mixed versions on the machine (this can lead to instability); depending on how your updating solution works, you may not recover from this until the following update is applied. But, aside from replacing a missing versioned file, or unversioned files in general, you don't have to worry about Windows Installer downgrading things.
(There are some other potential issues if you choose to deploy patches after a file has been updated—the base for the patch will likely not match the base on the machine and may require original source—but I'm assuming you'll test that scenario and work around or avoid it.)
MichaelU wrote: The full answer to this depends largely on which scenarios you care about supporting. From a Windows Installer perspective, you should be issuing some form of upgrade so that it can track the currently known version of the EXE. However, so long as things are versioned correctly, the most likely problem scenario is the updated file going missing and repair or auto-repair replacing it with the last version it knows about. Depending on the topology of your program, you may now have mixed versions on the machine (this can lead to instability); depending on how your updating solution works, you may not recover from this until the following update is applied. But, aside from replacing a missing versioned file, or unversioned files in general, you don't have to worry about Windows Installer downgrading things.
(There are some other potential issues if you choose to deploy patches after a file has been updated—the base for the patch will likely not match the base on the machine and may require original source—but I'm assuming you'll test that scenario and work around or avoid it.)
Thank you for the reply and this functionality seems to be working well.
Is there a way for an MSI to disable any attempt to repair, requiring a reinstall all together? I did remove the buttons from the install to not allow modify and repair, only remove, but I'm certain auto repair can still happen.
I'm reading somewhere that setting a file not to be a "Key" file will never invoke an autorepair on it.
I wouldn't recommend trying to fight auto-repair; the best answer to that question is typically to avoid MSI in the first place and use something like InstallScript. But it's almost always the wrong question.
There's a difference between whether a file may be a reason to run auto-repair and whether a file may be replaced during an auto-repair; the key-file question is more relevant to the first half, but file versioning rules will answer the second half. So remember that the auto-repair problem cases should only come up if the EXE is versioned poorly, or if the EXE goes missing. In all other cases, auto-repair should leave the EXE alone. So it's unlikely to be a major worry unless people with the privileges to remove files like to randomly target your EXE, and in that case, they should be prepared to have to fix things manually as well.
