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?
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 version numbers
Started by
dtasanas
, Jan 26 2005 20:17
4 replies to this topic
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.
Under that same keyword you can also find several flowcharts that explain the rules.
Stefan Krüger
InstallSite.org twitter facebook
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?
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
Posted 03 February 2005 - 11:32
typically not.
Did you perform an MSI validation and an Update validation?
Did you perform an MSI validation and an Update validation?
Stefan Krüger
InstallSite.org twitter facebook
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!
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