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.
Non-Versioned Files and the MSIFILEHASH
Started by
jetgeek
, Mar 24 2004 03:15
8 replies to this topic
Posted 24 March 2004 - 03:15
I am having problems with NON-VERSIONED files being overwritten by a earlier version of our products!!!
We have numerous installations that use the SAME merge modules and we update the files as we produce new products (the main install contains product specific stuff such as mdbs, readmes, etc.). So the ONLY EXE, set of DLLs, non-versioned files such as RPTs, MDBs, etc. reside in 3 or 4 merge modules that are SHARED between these products. So, Product1 uses msm1+msm2+etc. etc. and then we release Product2 and use SAME msms but update the files within and rebuild. Yes, we allowed Dev7 to auto-build the MSIFileHash for us...bad idea?
So, we had a few RPT files WITHOUT version numbers getting overwritten by an earlier product, EVEN though the dates of these files were MUCH MUCH later than the ones installed by the earlier product!
ARGHHHHHHHHHHHHHHHHHH!
Ok, I have searched this site and the community site and have not found answer this one...Help please?
Regards and Tanks, In advance!
jetgeek
Posted 24 March 2004 - 11:20
When overwriting non-versioned files Windows Installer doesn't use the date of the file inside your msi package. It only looks at the existing file and compares it create and modified date. If if was modified after it has been created (=installed) it assumes that the user has changed the file and doesn't overwrite it (to preserve user data). If the crate and modified dates are the same, or modified is older than create, the file will be overwritten.
To avoid this you can either mark the component as "never overwrite" (this also means that the new version will not overwrite the older version) or you can use companion files (see MSI help for details)
To avoid this you can either mark the component as "never overwrite" (this also means that the new version will not overwrite the older version) or you can use companion files (see MSI help for details)
Stefan Krüger
InstallSite.org twitter facebook
Posted 25 March 2004 - 21:03
Stefan,
Sorry, maybe I mis-spoke. NEWER FILES are being overwritten by OLDER files in an older install package.
I fully understand the concept of your reply and thank you very much for responding so fast...
However, the trick is that the files in question are contained in a MERGE MODULE which is shared between two or more installshield packages (Dev7 Standard). We add files or update files in the merge module and release it with a new product...
Our problem, is the Old product, ie PRODUCT1 comes along and OVERWRITES the NEWER PRODUCT2 installation of these same exact files! These files do not have a version (RPT, MDB, etc.).
I have been testing this until my fingers are raw...I built two test projects that share the same MSM. Sure enough, the PRODUCT2 files get overwritten by the PRODUCT1 files, EVEN THOUGH the PRODUCT2 files are LATER Dates!!!
What gives?
Tanks.
jetgeek
Posted 25 March 2004 - 21:28
Hi Stefan,
When we use verbose logging this is the message we get regarding an unversioned file:
When we use verbose logging this is the message we get regarding an unversioned file:
QUOTE |
MSI © (C1:59): File: C:\Program Files\PsychCorpCenter\Reports\WIATIIParentBellReport.rpt; Overwrite; No patch; Existing file is unversioned and unmodified - hash doesn't match source file |
In the release, we set Generate File Hash Values = Yes. When comparing the hash entries from one product to another they are different. Is this the right thing to do? Why is it overwriting? The date of the file is newer on the machine than the one they are installing.
Product 1 distributed July 2003 File Date: 07/22/03
Product 2 distributed December 2003 File Date: 12/14/03
Customer installed Product 2, file date 12/14/03
Customer bought and installed Product 1 after Product 2. Different products but same shared merge modules.
Product 1's file overwrites Product 2's newer file, Same component GUID, Same name, but different hash entries.
Any ideas??
Josiah
Posted 26 March 2004 - 14:54
As I already tried to explain: Windows Installer doesn't care which file is newer. It ONLY looks at the EXISTING file to see whether it has been modified after it has been installed. If it has, it will not be overwritte. If it's still the same as when it was installed, then it will be overwritten by the file you are installing.
Windows Installer doesn't KNOW about the date of the file you are installing. This information is not stored in the .msi file.
The hash shouldn't matter here. It only saves you from having to insert the old CD in cases where the hash matches.
Windows Installer doesn't KNOW about the date of the file you are installing. This information is not stored in the .msi file.
The hash shouldn't matter here. It only saves you from having to insert the old CD in cases where the hash matches.
Stefan Krüger
InstallSite.org twitter facebook
Posted 26 March 2004 - 15:44
Stefan,
AGAIN, many thanks for the swift answer...my team and our associated managers are all at DEFCON5.
So, you are saying that if we CHANGE the file's attributes at install time (like date, etc.) and then the old PRODUCT1 install comes along it will not overwrite the file?
Here is the scenario: FILENAME.RPT 3/1/04 installed by PRODUCT2, the FILENAME.RPT 7/23/03 installed by PRODUCT1 (BUILT earlier). (2)In this scenario the file gets overwritten. Are you saying this is by design by Installshield? If that is true, then I'm thinking we should have stayed with the PROFESSIONAL line (ie Pro7 from Pro6.x).
We had a analyst come to our department from Installshield and woe us to use MSI Basic (I like it too), but this little bug puts a "wrinkle" into our plans. Oh, did I mention we have 4 or 5 products already out in the field too? Looks like band-aid and triage time for me and my dev team...stat!
(2) Lastly, would linking companion files in the PRODUCT2 install prevent the non-versioned files from being overwritten by the PRODUCT1 install?
Tanks in advance, you have been a great help!
jetgeek
AGAIN, many thanks for the swift answer...my team and our associated managers are all at DEFCON5.
So, you are saying that if we CHANGE the file's attributes at install time (like date, etc.) and then the old PRODUCT1 install comes along it will not overwrite the file?
Here is the scenario: FILENAME.RPT 3/1/04 installed by PRODUCT2, the FILENAME.RPT 7/23/03 installed by PRODUCT1 (BUILT earlier). (2)In this scenario the file gets overwritten. Are you saying this is by design by Installshield? If that is true, then I'm thinking we should have stayed with the PROFESSIONAL line (ie Pro7 from Pro6.x).
We had a analyst come to our department from Installshield and woe us to use MSI Basic (I like it too), but this little bug puts a "wrinkle" into our plans. Oh, did I mention we have 4 or 5 products already out in the field too? Looks like band-aid and triage time for me and my dev team...stat!
(2) Lastly, would linking companion files in the PRODUCT2 install prevent the non-versioned files from being overwritten by the PRODUCT1 install?
Tanks in advance, you have been a great help!
jetgeek
Posted 27 March 2004 - 09:05
Yes, that's by design by Microsoft (not InstallShield - the MSI runtime engine is from MS)
Using a compantion, Windows Installer will no longer look at the file you are installing, but at the companion file. Ideally this would by a DLL with version number. If that DLL gets overwritten, it's companion clients will get overwritten, too.
Using a compantion, Windows Installer will no longer look at the file you are installing, but at the companion file. Ideally this would by a DLL with version number. If that DLL gets overwritten, it's companion clients will get overwritten, too.
Stefan Krüger
InstallSite.org twitter facebook
Posted 31 March 2004 - 19:04
Can you still associate a companion file to a file that already exists in the field? We have several shared files (unversioned) in the field. If we associate the companion file now, would there be any problem?
Josiah
Josiah
Posted 01 April 2004 - 08:09
No, for installations in the wild it's too late. You may want to do a Major Upgrade and handle this file using a custom action.
Stefan Krüger
InstallSite.org twitter facebook