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.

File versioning rules do not apply - why?

2 replies to this topic


  • Full Members
  • 11 posts

Posted 30 January 2015 - 16:39



I'm trying to do a major upgrade, conserving some non-versioned user specific files. As the "never overwrite" setting for components brings along the known problem of files missing after the upgrade process, I wanted to rely on file versioning rules.

My non-versioned file has an earlier creation than modification date, according to this https://msdn.microso...1(v=vs.85).aspx the file should be not be overwritten during a major upgrade. This is not the case, the log file mocks me with the following output:

Allowing installation of component: {x} even though a modified unversioned keyfile exists and file versioning rules would disable the component

Can anyone tell me why my setup behaves this way?


Some additional Info:

InstallScript MSI project

RemoveExistingProducts is scheduled between InstallValidate and InstallInitialize

The REINSTALLMODE property is not set at all during my setup (at least it does not show up in the log). It appears if I set it to "omus" manually but that doesn't help.


Thanks a lot for any help.


  • Moderators
  • 1,447 posts

Posted 03 February 2015 - 10:32

There could be several reasons for this:

  • A companion file means that the file's reinstall behavior is defined by another file (generally a versioned one) - I believe this could overwrite a non-versioned, changed file. See this thread: http://forum.install...c=21705&p=61015
  • Though you say you didn't, it is still relevant: You could also have set a custom REINSTALLMODE on the msiexec command line (REINSTALLMODE = "amus" or similar) which changes the overall behavior of the MSI file versioning rules (amus means replace all files and should never be used since it can downgrade system files - on later versions of Windows that generally triggers a runtime error, on lower versions a replaced system file that is then fixed from the dllcache system file protection feature).
  • I also think Installshield features a non-standard way to simulate the "amus" behavior on a single component basis by setting a flag called "always overwrite" or similar for the file itself (I believe this sets the file version field inside the MSI to the maximum version value). This feature may only be available in Installscript MSI and not in Basic MSI - I am not sure. See here for a screenshot: http://stackoverflow.com/a/24271734

I suppose there could be other causes, but please check the above first.

Edited by Glytzhkof, 03 February 2015 - 11:05.

-Stein Åsmul


  • Full Members
  • 11 posts

Posted 06 February 2015 - 13:04

Thanks for your proposals, unfortunately neither of these could help me:


  • The files that are unintentionally overwritten are all the only ones in their respective components, set as key files and do not have companion files.
  • I'm not a hundred percent sure whether REINSTALLMODE is set correctly, because the property is not listed anywhere in my setup log. I tried setting it to "omus" via the command line, which lead to it appearing in the log, but that didn't solve the problem.
  • "Always overwrite" is deactivated for the problematic files.