6 replies to this topic

[Pizzero]

Dear forum,

I want to overwrite a file reliably upon installation (first-time, upgrades, ...).

(It is a program file, which does not contain any user-relevant data but it is modified, after is has been used - and no it's not a virus but an MS-Access file. Therefore to deploy the most recent code it's crucial to overwrite this file always)

There are various techniques to accomplish this:

* Delete the file before installation (RemoveFile, CustomAction, ...)
* Use a file version and increase it for new versions.
* Use a file version of 65535.0.0.0 (InstallShield 12)
(and a few more)

Now I don't understand why the latter should work (but I have verified this!) - the MS pages clearly state that when the file version is equal (here it is always 65535.0.0.0) then the file will not be overwritten!

http://msdn.microsof.....28VS.85).aspx

When the MS specs use the term "file version" what do they refer to? The version as authored into the msi-package or as found by analyzing the file (MS-Access files do not have a file version accessible via right-click properties)? And is this different for files still on the source medium or already installed?

I use the InstallShield method (because I use this software), but wouldn't be the most straightforward and easiest method be to simply delete the file before installation? What do you recommend?

Best regards,
Pizzero

Edited by Pizzero, 26 August 2009 - 14:38.

[VBScab]

For me, the key words in your request are "overwrite" and "reliably". On that basis, I'd go with using the RemoveFile table. If it's deleted before the installed files begin being copied, I'd say it had been "reliably overwritten."

Edited by VBScab, 26 August 2009 - 16:45.

[Pizzero]

VBScab, thanks for confirming, what I already supposed!

But what about the concept of file versioning, for example what's the version of a file in MSI-speak: the msi-coded version or the version coded into the file? And what about the 65535.0.0.0 trick?

Would really like to know more about this -
best regards,
Pizzero

[VBScab]

When comparing versions, the WI engine uses the embedded info in the file itself and checks it against the version info stored for its replacement in the MSI. Because the information in the MSI is extracted from the file when the MSI is built, it should be accurate.

As for the 65535.0.0.0 trick? Dunno, never used it. I either overwrite it using versioning rules or delete it using the RemoveFile table. I'm a simple soul!

Edited by VBScab, 26 August 2009 - 17:09.

[Pizzero]

Ahh, I see. It's also the only possibility to explain why the 65535.0.0.0 trick works - an installed file, if versioned or not will always be overwritten by a file with a version of 65535.0.0.0 authored into the msi package (supposing the version of an installed and versioned file will never be 65535.0.0.0).

What a pitty that Microsoft specs miss to explain that a file version of an installed file is the version in the file stream and that a file version of a "not installed" file is determined by the information stored in the msi package (, ignoring the version in the file stream - if I understood it correctly).

Thanks a lot VBScab!

[Stefan Krueger]

The version of an existing file is the version of the file on the target hard disk. The file in your setup media (or stream if embedded in the .msi file) is never used. Instead the information in the File table is used.
Problem with the Installshield trick is that the existing file will always look older (because it doesn't have a version at all, or its version is < 65535) than the the information in hte File table of the msi, so it will always be replaced - even during a (auto-)repair of the currently installed package. WIndows Installer's health check might even trigger a repair because it thinks that someone has downgraded the file.
Companion Files is another way to handle version-less files.

[VBScab]

As ever, MSDN is a good place to check.