Warning WIX1148: Invalid MSI package version

[gitfool]

We're using "deterministic" versioning in builds using the git commit date time formatted in a way captured by the following PowerShell:

function Get-Version
{
    $commitDate=(git -c log.showSignature=false show --format='%cI' -s)
    $version=[System.DateTimeOffset]::Parse($commitDate, $null, [System.Globalization.DateTimeStyles]::AdjustToUniversal).ToString("yyyy.Mdd.Hmm")
    $semver=[System.Text.RegularExpressions.Regex]::Replace($version, "(?<=\.)0+(?=\d)", "")
    $semver
}

Note that leading zeroes, possible in the patch version (Hmm), are stripped so any NuGet package artifacts are SemVer 2.0 compliant.

Anyway, I've just found out that one of our repos builds an installer using WiX, and since it binds the deterministic file version from a build artifact to the "product" version:

<Wix xmlns="http://wixtoolset.org/schemas/v4/wxs">
  <Package Language="1033" Name="$(var.ProductName)" Manufacturer="$(var.CompanyName)" UpgradeCode="$(var.UpgradeCode)" Version="!(bind.fileVersion.file_service_artifact)" InstallerVersion="300"><SummaryInformation Description="$(var.ProductName)" />
  ...
  </Package>
</Wix>

... it throws the following warning during the build:

Warning WIX1148: Invalid MSI package version: '2024.501.629.0'. The Windows Installer SDK says that MSI product versions must have a major version less than 256, a minor version less than 256, and a build version less than 65536. The revision value is ignored but version labels and metadata are not allowed. Violating the MSI rules sometimes works as expected but the behavior is unpredictable and undefined. Future versions of WiX might treat invalid package versions as an error.

We can't/won't drop using this deterministic versioning and we'd prefer to consistently use the same version everywhere, including for the MSI product version, so my question is can this be safely ignored or will it eventually be promoted to an error?

Also, there seems to be an issue that when building with "warnings as errors" this cannot be suppressed with:

<Project Sdk="WixToolset.Sdk/4.0.5">
  <PropertyGroup>
    <NoWarn>$(NoWarn);WIX1148</NoWarn>
  </PropertyGroup>
</Project>

What am I missing?

[gitfool]

Re the warnings as errors, I found what I was missing which were the WiX-specific MSBuild properties:

<Project Sdk="WixToolset.Sdk/4.0.5">
  <PropertyGroup>
    <SuppressSpecificWarnings>1148</SuppressSpecificWarnings>
  </PropertyGroup>
</Project>

... which then leads to the following validation error:

Error WIX0204: ICE24: ProductVersion: '2024.501.629.0' is an invalid version string.

This can also be suppressed with another WiX-specific MSBuild property:

<Project Sdk="WixToolset.Sdk/4.0.5">
  <PropertyGroup>
    <SuppressIces>ICE24</SuppressIces>
    <SuppressSpecificWarnings>1148</SuppressSpecificWarnings>
  </PropertyGroup>
</Project>

So now I can coerce a build with warnings as errors, with the above suppressions, but the question remains - can this be safely ignored or will it eventually be promoted to an error?

[robmen]

can this be safely ignored ...?

No, not really. The behavior is undefined. There is a Deployment Dojo episode (maybe S1:E4 - Out with the Old. In with the New. ?) where I explore the ins and outs of it. If it isn't that episode, it's probably in one of the two after it. It's interesting to hypothesize what is going on because they don't document it.

If you really want to do what you're doing with version numbers in your MSI file, you'll need to file a feature request with Microsoft.

Note: Burn can handle such version numbers (and many more complex ones).

[gitfool]

How would I use burn to handle such version numbers?

[bevanweiss]

Here's a reference to the Burn WIP in that direction https://wixtoolset.org/docs/development/wips/burn-engine-semantic-versioning/
It would be quite a bit of extra effort to go from MSI->Burn just for more flexible versioning.
But you have mentioned that it's a non-negotiable, so you'd have to hit the learning curve for doing a Burn bundle ontop of the MSI authoring... or contract it out to the likes of Rob / Bob (@firegiant.com)