Invalid product versions for NSIS when packaging in CI

[DiedB]

• Version: 20.1.1

• Target: NSIS (Windows)

The product version (X.X.X.X) is given to NSIS as a command line variable called VIProductVersion. This build number is generated by the function versionInWeirdWindowsForm() (which can be found in packages/electron-builder-lib/src/appInfo.ts). To fill in the last digit, which is not present in Node, it uses the build number environment variable or 0 if this is not present. It is set as follows, in the same file:
this.buildNumber = process.env.BUILD_NUMBER || process.env.TRAVIS_BUILD_NUMBER || process.env.APPVEYOR_BUILD_NUMBER || process.env.CIRCLE_BUILD_NUM || process.env.BUILD_BUILDNUMBER
However, it is not checked whether this environment variable is actually numeric. In case of Visual Studio Team Services (and probably other CI providers as well), this variable is alphanumeric (resulting in 1.2.3.Build123 for example). When NSIS is started to create the installer package, an invalid build number is passed making it throw an error and stop packaging.

This problem should be handled by Electron Builder. I suggest detecting an alphanumeric value and setting the build number to 0 if this is the case, preventing errors.

[woutderooms]

I can acknowledge, I had a very obscure error:

VIProductVersion expects 1 parameters, got 4.
Usage: VIProductVersion [version_string_X.X.X.X]

My workaround was to use cross-env to set the BUILD_NUMBER env variable to 0

Example (in scripts in package.json):

"dist": "cross-env BUILD_NUMBER=0 electron-builder --win",

[DiedB]

There might have been spaces in your build string format, causing makensis.exe to see multiple arguments?

I use the same workaround by the way, but I forgot documenting it. I hope it gets resolved so I can remove the workaround.

[develar]

https://stackoverflow.com/a/37070889

Fixed, thanks for clear issue report.

[semireg]

We have a legitimate need for the build number to be appended to version for appx releases. See #3875 for details.