Support for setting the ARP DisplayVersion separate from the Version

[MichaelKetting]

• Describe the scenario and benefits that the feature supports:

Windows "Programs and Features" (ARP) supports a free-text display version at HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall{product code} Presently, WIX will use the Wix\Product@Version attribute to set the DisplayVersion and the Version values in the Windows Registry without a way to specify separate values. This means it's not possible to tell the user that a version is, e.g. an alpha version because the Version must be in the numeric 3-part (or 4-part) version scheme.

• Describe how you're accomplishing the feature today (if possible):

I don't have a solution for this, given how I cannot use custom Registry entries to override this value and there is also no ARP-property (like ARPPRODUCTICON for instance) to specify an override.

• Describe what you'd like the new feature to do:

A new ARP-property, so I can write

<Wix>
  <Product Id="$(var.ProductCode)" Version="1.2.3">    
    <Property Id="ARPDISPLAYVERSION" Value="1.2.3-alpha.1" /> 
  </Product>
<Wix>

[barnson]

WiX doesn't write those values; that's Windows Installer, which doesn't support what you're looking for.

[MichaelKetting]

@barnson thanks for getting to this so quickly :) I could only work with what I was able to reverse engineer from the WIX source code, but in Microsoft.Tools.WindowsInstallerXml.Binder.CreateBurnManifest there is the following line: writer.WriteAttributeString("DisplayVersion", bundleInfo.Version);

Binder, in turn, seemds to be used by light.exe to create the registration file which is then passed internally to burn.exe which creates the msi-package. So, changing DisplayVersion to use a separate value (with bundleInfo.Version only as the fallback), it looks like it should pass the values into the right pipeline.

Am I completely wrong aobut those assumptions?

[barnson]

Burn is for bundles, not MSI packages. Bundles could write an alternate version; MSI packages cannot.

[MichaelKetting]

Thanks for clearing that up. Now I also understand better what the documentation on MSDN was trying to tell me. Guess this can be closed as won't-fix then :(

[barnson]

More like can't-fix. :)

[smaudet]

Possibly should be re-opened - there's some bug somewhere in wix where it is taking e.g. 1.1.0001 and turning it into 1.1.1

I have two msi, one is produced a different way (non-wix) and contains 1.1.0001, the one produced with wix contains 1.1.1

My wxs file contains <Package Version="1.1.0001" ...>

So this must be Wix at fault (not an MSI issue).

DisplayVersion is separate and is something that could be done with a registry key/custom task. I dislike how little control is given over the msi production process in WiX (especially as I'm actually invoking it via wixsharp).

[robmen]

@smaudet, don't comment on an issue that was closed over seven years ago, suggesting that it needs to be reopened. A lot can change in seven years. Look for a recent issue that might explain why there is a difference in behavior. If you don't find one, feel free to start a discussion to understand why the current behavior is what it is. Often there is a reason. Sometimes it's just a bug.

[smaudet]

@robmen I did actually check for bugs, didn't find one. Search pointed me here, the "we can't support this its not supported by msi" is technically incorrect (you can, just not through just msi). That would be the reason to re-open this "bug" i.e. feature.

I was going to eventually open a new bug: https://github.com/wixtoolset/issues/issues/8589

However I also find your response a bit condescending.