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

File version numbers


4 replies to this topic

dtasanas

dtasanas
  • Full Members
  • 83 posts

Posted 26 January 2005 - 20:17

from what i have learned MSI only deals with the first 3 parts of a version number: maj.min.build

what if your product had 4 version numbers: maj.min.xx.build

how will MSI behave when given files with 4 numbers instead of three on a build to build basis.

IE:
build 1.1.0.100 produces files with version 1.1.0.100

then upgrade to 1.1.0.101 with versions 1.1.0.101

do dates and times come into play in this situation? how does MSI decide what to replace and what to leave behind?
Don Tasanasanta[br]Configuration/Installation Eng

Stefan Krueger

Stefan Krueger

    InstallSite.org

  • Administrators
  • 13,269 posts

Posted 27 January 2005 - 12:14

QUOTE
from what i have learned MSI only deals with the first 3 parts of a version number: maj.min.build
This restriction onyl applies to the ProductVersion property of your package.
QUOTE
how will MSI behave when given files with 4 numbers instead of three on a build to build basis.
File overwrite rules will always consider all four fields of the file version resource.
QUOTE
do dates and times come into play in this situation?
No, only for unversioned files (like text files, databases, graphics files and the like).
QUOTE
how does MSI decide what to replace and what to leave behind?
This is a complex process that is described in MSI help topic "File Versioning Rules" at http://msdn.microsof...oning_rules.asp
Under that same keyword you can also find several flowcharts that explain the rules.

dtasanas

dtasanas
  • Full Members
  • 83 posts

Posted 03 February 2005 - 00:49

the reason i ask is this...

we version our files on a 4 digit version number x.x.xx.xxxx (ex. 1.0.0.1234)

we've been able to install one build over another without any problem until one day a build came out (lets say: 1.0.0.1235) that refused to upgrade on top of another build (1.0.0.1234).

that made me wonder about the version numbers and if we were going too far out with our 4th place digit.

subsequent builds (after 1.0.0.1235) have been able to upgrade on top of one another. but none of the later builds have been able to upgrade over the older builds (1.0.0.1234 and before).

so i looked at the differences in the MSI's between these two builds. the only difference is the addition of a component (EXE) to the component table.

can adding an EXE cause upgrades to fail?
Don Tasanasanta[br]Configuration/Installation Eng

Stefan Krueger

Stefan Krueger

    InstallSite.org

  • Administrators
  • 13,269 posts

Posted 03 February 2005 - 11:32

typically not.
Did you perform an MSI validation and an Update validation?

dtasanas

dtasanas
  • Full Members
  • 83 posts

Posted 03 February 2005 - 23:34

oh wow! the validation tool helped a lot!

apparently i also removed several merge modules.

this was too much of a difference thus requires a minor change in version numbers to effectively execute the upgrade.

thanks!
Don Tasanasanta[br]Configuration/Installation Eng