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 being over written


7 replies to this topic

Jim Bassett

Jim Bassett
  • Members
  • 22 posts

Posted 27 January 2004 - 15:47

We have products that make use of DLLs, help files, and XML files and these are shared between the products and there are different MSI installations to install these files. What we have discovered is that suppose Product A has the latest version of these DLLs, help files, and XML files and is installed.

Product B has earlier versions of these files and a customer installs these toa PC that product A was installed on earlier.

The DLLs that were installed with Product A, being the latest version were not overwritten by the earlier version of DLLs from the installation of product B.

But the latest version of the help files and XML files installed as part of product A are overwritten by the installation of Product B.

As our engineers understand it the DLLs have versions with them so MSI can tell not to over write them with the earlier version but since help files and XML files only have dates with them then MSI will go ahead and over write.

One engineer read that the over written files could be associated with one or more of the dlls, what is called companion files so that they will not over written.

Surely there is some method that is part of MSI or DevStudio that can be setup to address not updating files such as help files, XML , text files, etc. when they are the latest version.

What are we missing here?

Balachandar

Balachandar
  • Members
  • 23 posts

Posted 27 January 2004 - 17:22

In your MSI database, check for the MsiFileHash table if there are any values written.

This table contains the date,size information of a file which is also used before replacing.

dGabay

dGabay
  • Members
  • 22 posts

Posted 27 January 2004 - 19:38

Hi,
I'm the engineer mentioned above. There are no entries in MsiFileHash. Should there be? Thanks for your help.

Glytzhkof

Glytzhkof
  • Moderators
  • 1,447 posts

Posted 27 January 2004 - 22:16

If you tweak the non-versioned files to have different create and modify dates windows installer will not overwrite them. There is also a property you can set for the component that says "never overwrite". Finally you could "null out" the component GUID for the file you don't want overwritten. This is just a hack, but if you do this windows installer will install the file and never "touch it" afterwards.
Regards
-Stein Åsmul

Glytzhkof

Glytzhkof
  • Moderators
  • 1,447 posts

Posted 27 January 2004 - 22:31

One more thing: user settings files like these should really be installed to the userprofile folders. I tend to install these files to a read-only location in %PROGRAMFILES% and then have the application copy them down to the userprofile folder (if it is a user specific file), or to the allusers folder if it is shared among all users. The benefit of this is that you can overwrite the file in %PROGRAMFILES% with a new version, but still preserve the version the user has already customized. There are problems with this apporach too of course such as how do you "force" a setting to be added to the userprofile file. The answer to this is usually "have the application update the settings file "on load".
Regards
-Stein Åsmul

Balachandar

Balachandar
  • Members
  • 23 posts

Posted 28 January 2004 - 10:24

To populate the MsiFileHash table, run MsiFiler.exe from Microsoft on MSI file. This will populate your MsiFileHash table and the Date will also be used as a citeria before replacing.

Ofcourse there are other tweaks as mentioned in the forum already.

Cheers.

sjimmerson

sjimmerson
  • Members
  • 36 posts

Posted 28 January 2004 - 17:09

It seems like an oversight on Microsoft's part not to at least give you the option to overwrite a file on a PC that has an older modification date than the one in installation. This is the way IS 5.5 does it and according to the documentation DevStudio 9 InstallScript projects do it this way too.

If this is not an oversight I would like to know why Microsoft decided it shouldn't at least be an optional way to overwrite non-versioned files. If anyone has any inside information they would like to share or just care to make an educated guess as to why this is the case, please do so.

Glytzhkof

Glytzhkof
  • Moderators
  • 1,447 posts

Posted 28 January 2004 - 22:24

I believe specifying REINSTALLMODE=amus will cause all files to be replaced regardless of version and checksum. This is the "hammer approach" that you normally shouldn't use. I am not quite sure if file hashing will override the amus REINSTALLMODE value, but I don't think so. The problem with REINSTALLMODE is that it applies globally to the whole installer - which will include merge module files as well... Not good.

I believe the whole file versioning logic of Windows Installer has its background in "DLL hell". By allowing force overwriting of lower version files people get more rope to shoot themselves in the foot with. When the installer itself enforces rules to prevent this one would think that it solves some problems. Unfortunately the force overwriting of existing files, and particularly unversioned files, is something that many setup developers and applications rely on.

In general I think that unversioned files shouldn't be changed by the application. Any settings files should go into the userprofile folders and from then on remain untouched by the installer. The %PROGRAMFILES% folder would then be completely read-only. However, I don't think many share this opinion with me.

Edited by Glytzhkof, 28 January 2004 - 22:25.

Regards
-Stein Åsmul