8 replies to this topic

[jetgeek]

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

[Stefan Krueger]

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)

[jetgeek]

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

[jleverich]

Hi Stefan,

When we use verbose logging this is the message we get regarding an unversioned file:

[Stefan Krueger]

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.

[jetgeek]

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

[Stefan Krueger]

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.

[jleverich]

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

[Stefan Krueger]

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.