I recommend they use xcopy exclusively. Give them a ZIP file.
Actually, the installer should overwrite whatever's already there. The rules
for first installs and major upgrades are clear:
If both the existing file and the new file have a version number, highest
version wins. If the version is the same, no upgrade occurs.
If only the new file has a version, the existing file is overwritten.
If only the old file has a version, the existing file is kept.
If neither file has a version, and the existing file has been modified
(LastWriteTime different from CreationTime), it is kept.
If neither file has a version and the existing file is unmodified, the new
file overwrites the old one. As an optimisation, if the installer contains a
hash for the file (WiX always generates hashes) and the hash of the existing
file is the same, the new file is not copied. This saves a little write I/O
and potentially saves extracting the file from the CAB, and even downloading
the CAB or file if installling from an administrative install point or from
the Web.
These rules only apply to the key path of each component. If the key path is
determined to need upgrading, the whole component is installed. With WiX,
the first file mentioned in the Component is the key path, unless you
explicitly set it with the KeyPath attribute. Optionally, you can tell
Windows Installer to use a different file for version decisions (a
CompanionFile) but you're not allowed to do this if the file is the key path
for its component.
It's possible that if they're xcopying, the modified date becomes different
from the creation date. In this case Windows Installer thinks that this is
user data it's supposed to be protecting and won't overwrite it. Xcopy
doesn't offer any options to work around this.
--
Mike Dimmick
_____
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Matthew
Janulewicz
Sent: 12 June 2007 18:08
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Clear out directory before install?
I realize this is a certifiable Bad ThingT, but it's a situation I haven't
much control over. Here's what's going on.
Deployment crew deploys website or application .msi's to one set of our
production servers.
Instead of using the .msi's on all our redundant servers, they xcopy it over
to multiple other servers.
Next month, deployment crew does the same thing except that they start on a
different server, one of the xcopy servers. So the new .msi does not
overwrite anything on that server. Then they xcopy it to the original server
and regress everything back to where it was last month.
Everyone spends half a day trying to figure it out before anyone asks CM
about the installers. Problem is then discovered in about 10 seconds.
CM gets blamed for having bad installers.
I've suggested they 'use the installers correctly' but apparently this is
too difficult.
There is no 'extra stuff' in any of the directories, so if I could wipe them
out completely before the .msi starts <InstallFile .> it would solve this
'problem'.
Essentially I'm looking for a way to delete items that are not in the file
table in an installer prior to installing. I've tried <RemoveFile . /> but
it doesn't seem to work in the way I would like it to. Or else I'm not doing
it right. Any ideas?
----------
Matthew Janulewicz
SCM Engineer
Green Dot Corporation
[EMAIL PROTECTED]
(626) 775-3857
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
