msi version numbers

Yes, FileVersions and ProductVersions are unrelated. ProductVersion is shown in Add/Remove Programs ( Programs and Features ) and is mainly used during Major Upgrade scenarios to decide what should happen.

ProductVersion Property is defined as [0-255].[0-255].[0-65535] ( 8,8,16 signed bit respectively) File Version is defined as [0-65535].[0-65535].[0-65535].[0-65535] ( 16,16,16,16 signed bit... )

Text/XML/Config/BMP ectera will be null. Typically your authoring tool (such as InstallShield) will reflect your versioned PE files (DLL,OCX,SYS,EXE...) at build time and author their version numbers into the File table automatically.

There is also an option in InstallShield called "Always Overwrite" that "version lies" to MSI at build time and tells it that your non-PE file (TXT/XML....) really has a version number ( typically 65535.0.0.0 ) this exploits the behavior in MSI that Versioned Files Trump Non-Versioned files when deciding to overwrite or not.

Tecnically an EXE can be non-versioned but that's an anti-pattern. A non-versioned file is any file that doesn't have an embedded version resource record.

Another thing to understand that is by default Windows Installer looks at the creation date and modification date of the target file when deciding if the src file should overwrite the target. If CD and MD re equal it's considered 'virgin' (my term ) and the overwrite occurs. If they are not equal it's considered 'user data' and it's not overwritten unless you do the Always Overwrite trick.

Another thing to understand is these evaluations occur at the keyfile level of the component. Any other companion files in the component ( if not following 1:1 file per component guidelines ) will follow the dirction of the key file.

Also realize there is a difference between AssemblyVersion and AssemblyFileVersion. The .NET AssemblyFileVersion attribute is what maps to the legacy FileVersion attribute. The AssemblyVersion attribute is only used for purposes of Strong Naming and MSI doesn't care about it.

Finally, google "Windows Installer Component Rules" for more information.

Please let me know if this makes sense and if you have any additional questions. You actually asked about a dozen questions in one question so I might miss something. Also please feel free to accept this answer.


Yes, MSI ProductVersion and version in MSI file table are unrelated.

Yes, FILEVERSION in VERSIONINFO can be used to set the version in the MSI file table.

Version terms in context

When working with MSI version, the numbers are often retrieved from VERSIONINFO resource (used in resource files) or .NET assembly contexts. The MSI terms might be easier to understand when compared with those:

Version

  • Windows installer: a string data type, used in the MSI file table for the files it contains
  • Resource files: data type consisting of 2x32-bit integers
  • .NET assembly: AssemblyName.Version might be comparable

Product version

  • Windows installer: a string property (as such it can be found by Orca/SuperOrca within an MSI file)
  • Resource files: PRODUCTVERSION, a statement using the version data type
  • .NET assembly: AssemblyVersion, using AssemblyName.Version

File version

  • Windows installer: is neither a property nor a data type. It is used as term to combine version string & language string. The windows installer methods Installer.FileVersion and MsiGetFileVersion ...

    [..] return the version string or language string

    No "FileVersion" property exists in the MSI.

  • Resource files: FILEVERSION, a statement using the version data type
  • .NET assembly: AssemblyFileVersionAttribute

Version number restrictions

The version data type in Windows installer - despite being a string - has the same limitations as the version data type in resource files ...

The version consists of two 32-bit integers, defined by four 16-bit integers.

... as well as the AssemblyName.Version ...

Metadata restricts the major, minor, build, and revision components for an assembly to a maximum value of UInt16.MaxValue - 1

So in case:

  • the program is built using a resource file
  • PRODUCTVERSION or AssemblyVersion are used for the MSI ProductVersion property during the build/deploy process

the developers has to heed:

  1. The limitations of VERSIONINFO/AssemblyName.Version (unsigned 16bit.16bit.16bit.16bit) and
  2. The limitations of Windows installer for product version (unsigned 8bit.8bit.16bit), while the fourth field doesn't matter:

    If you include a fourth field in your product version, the installer ignores the fourth field.

So programs used in deploy processes which uses the version number of programs for their MSI setup have to heed the following limitations:

  • PRODUCTVERSION/AssemblyVersion: 8bit.8bit.16bit-1.16bit-1 (unsigned int)
  • FILEVERSION/AssemblyFileVersion: 16bit-1.16bit-1.16bit-1.16bit-1 (unsigned int)

Please point out weaknesses/faults of those comparisons.

Tags:

Windows Installer

Recent Posts