Jump to content


This is a ready-only archive of the InstallSite Forum. You cannot post any new content here. / Dies ist ein Archiv des InstallSite Forums. Hier können keine neuen Beiträge veröffentlicht werden.
Photo

Files do not get replaced when updating


8 replies to this topic

sookie

sookie
  • Members
  • 10 posts

Posted 21 January 2004 - 15:54

Hi,

this is probably pretty much a rookie question, but I couldn't find a solution using the search feature of this forum. Sorry about that.

Anyway:
We are using InstallShield Developer 7.0 to build the msi. I am trying to perform an update of our product (a) with the following command line:

msiexec /i "product_a.msi" /L*V reinstall.log REINSTALLMODE=vomus REINSTALL=all ALLUSERS=2 INSTALLDIR=c:\Programme\product_a

The files of the product do not get replaced, although the source files differ in size and timestamp from the installed files. However, the version information that is displayed under Control Panel - Software shows the updated version number.

When using the same command line on our product (b) the files do get replaced:

msiexec /i "product_b.msi" /L*V reinstall.log REINSTALLMODE=vomus REINSTALL=all ALLUSERS=2 INSTALLDIR=c:\Programme\product_b

When comparing the log files I can see that in case of the successful replacement (b) ComponentRegister gets executed, showing the appropriate KeyPaths to the files to be replaced - which doesn't happen in case (a).

Any possible hints why the files do not get replaced in (a)? If you need further details, please let me know.

Thanks,
Oliver.

Stefan Krueger

Stefan Krueger

    InstallSite.org

  • Administrators
  • 13,269 posts

Posted 22 January 2004 - 10:32

Do the files also differ in version? Date and size doesn't matter.

Look through the log for any indication that you broke component rules.
What is the Installed, Request, and Action state for the features and components?

sookie

sookie
  • Members
  • 10 posts

Posted 22 January 2004 - 12:26

Thanks for the quick reply,

the log files indicate the following problem:

8<--8<--8<--
MSI © (6C:64): SELMGR: ComponentId '{6BF15266-4811-4FB1-9631-8AEE142F61A4}' is registered to feature 'bin', but is not present in the Component table. Removal of components from a feature is not supported!
MSI © (6C:64): SELMGR: The feature-component mapping registration is broken for feature 'bin' of product '{5C947520-A1BA-4F6D-8043-2985561455C8}'
8<--8<--8<--

The reason is: a number of files were removed from the project before building a minor upgrade.

After building a new release for a major upgrade with modified package code, product version and product code, the files were replaced when performing another upgrade installation as described in my first message.

So step one of our problem is resolved. Thanks for that, again.



But I have another question related to that:
A database system and its data files (containing default data at initial installation) are part of our product distribution. The data stored in the database will be modified during the product use.

When just using the msi mentioned above with an msiexec and the parameters as described in my first message, the resulting data directory holds files that were created during product use (which were not contained in the default install) and files that were modified during product use are replaced with older versions from the update procedure. That corrupts the database, of course.

What is the smartest way of handling the situation where I do not want to touch the directory that contains the database and subdirectories holding the customer modified data, i.e. perform the install if the database directory is not there, do not replace data if it's already there?

When setting the "Never overwrite" property to "yes" on all the components related to the database, the files still get replaced. No matter whether I run
msiexec /i "product_a.msi" /L*V install.log ALLUSERS=2 INSTALLDIR=c:\Programme\product_a
or
msiexec /i "product_a.msi" /L*V reinstall.log REINSTALLMODE=vomus REINSTALL=all ALLUSERS=2 INSTALLDIR=c:\Programme\product_a

Any thoughts how to handle this?

Err... Is it possible that keeping installed files is just not possible with a MAJOR UPGRADE as an unistall/install is performed?

Edited by sookie, 22 January 2004 - 12:37.


Stefan Krueger

Stefan Krueger

    InstallSite.org

  • Administrators
  • 13,269 posts

Posted 23 January 2004 - 09:35

never overwrite doesn't work in a major upgrade if you have RemoveExistingProducts early in the sequence. You could move it down to avooid this.
Another option would be to mark these files also as Permanent so they will never be deleted: not during update and not during uninstall. In general you should never delete user data.

sookie

sookie
  • Members
  • 10 posts

Posted 23 January 2004 - 11:00

I'd rather not modify the sequence of actions significantly, as I am not that familiar with the topic yet.

What happens if I mark the files as permanent in the upcoming Major upgrade which is going to be deployed considering that
- the files were (of course) not marked as permanent in the preceding updates
- the files may have to be modified in future releases due to data base changes - i.e. can I change the flag back and will the files be replaced then?

What I did to ensure the data will remain intact when performing the update is adding a backup and restore custom action before and after the actual removal / installation. Using the script language, that simply XCopies the relevant directories and files to a temp directory and restores them once the installation procedure is through.



Stefan Krueger

Stefan Krueger

    InstallSite.org

  • Administrators
  • 13,269 posts

Posted 23 January 2004 - 11:14

You would have to do this in the old version, and you cannot change this after the fact.
Backing up and restoring (or converting if necessary) the files is also a viable option. Be sure to handle aborrted installs (rollback) properly.

sookie

sookie
  • Members
  • 10 posts

Posted 23 January 2004 - 11:48

I guess that's the knockout criterion then.
So backing up and restoring is the way I'll stick to.

I'm not quite sure if the roolback handling is okay - I organized the actions as follows:

[...]
InstallValdiate
c - BackupDatabase
RemoveExistingProducts
InstallInitialize
[...]
c - cacls.exe
InstallFinalize
c - RestoreDatabase
[...]

As far as I understand it InstallInitialize and InstallFinalize mark beginning and ending of the transaction. As the custom actions Backup and Restore are not contained in the transaction I assume the correct state would be recreated as the script functions check if a backup (and restore as a consequence) is required and simply perform that outside of the transaction.
If the transaction is rolled back it may be possible that an unnecessary restore will be performed. But that wouldn't do any harm as it just recreates the state before the transaction was started.


Something I forgot to mention: Backup and Restore are both scheduled for immediate execution. This is the reason why I was kind of confused when the restored data was overridden again by the installation actions when I still had Backup and Restore between InstallInitialize and InstallFinalize...

Edited by sookie, 23 January 2004 - 14:25.


ricklin

ricklin
  • Full Members
  • 5 posts

Posted 01 June 2005 - 17:45

Hi Stefan,

You said "never overwrite doesn't work in a major upgrade if you have RemoveExistingProducts early in the sequence. You could move it down to avooid this."

How far down the sequence do you recommend moving RemoveExistingProducts to? Can you recommend between which 2 standard sequences RemoveExistingProducts should go to? I have fairly simple Basic Msi Install with no custom actions. Thanks.



Rick

Stefan Krueger

Stefan Krueger

    InstallSite.org

  • Administrators
  • 13,269 posts

Posted 02 June 2005 - 09:58

A description of possible sequence positions can be found at http://msdn.microsof...ucts_action.asp
The last two bullets in that article should work because the new files are installed on top of the existing files, and only obsolete files are being removed.