Windows target ignores ${arch} variable in artifact name?

[thomasjm]

• Version: 17.0.3
• Target: passing args build --x64 --win --publish always (so it's using the default NSIS target)

I've noticed that when building my windows target, the name is always of the form MyApplication-1.0.0.exe, even though I explicitly specified an artifactName like this:

"build": {
    "win": {
        "artifactName":  "${productName}-${version}-${arch}.${ext}"
    },
}

I saw the comment here, where is says "If no arch, macro will be removed from your pattern with leading space, - and _". I haven't been able to figure out in which circumstances there is or isn't an arch, though. I'm assuming that the generated .exe works on both ia32 and x64?

If so, this is all well and good, but I really do need to product artifacts with different names like MyApplication-1.0.0-ia32.exe and MyApplication-1.0.0-x64.exe, because I need to include special architecture-specific binary resources via extraResources, like this:

"extraResources": [{
    "from": "binaries/${os}/${arch}",
    "to": "."
 }]

Is it just not possible to create Windows installer .exe files with the ${arch} variable in them?

(I realize that I could just rename my installers after building, but I would like to be able to directly publish them using the --publish flag)

[thomasjm]

Note: I was able to work around this using an environment variable and ${env.ENV_NAME}

[develar]

Please see #1389 (comment)

[develar]

I really do need to product artifacts with different names like MyApplication-1.0.0-ia32.exe and MyApplication-1.0.0-x64.exe, because I need to include special architecture-specific binary resources via extraResources

Doesn't matter. "Nsis installer contains both archs."

[thomasjm]

Ah, thanks for the pointer. Follow-up question--so the extraResources from both architectures are included in the final artifact? That doesn't seem too good if they're large...

[thomasjm]

@develar, still confused here -- I confirmed that the dist/win-unpacked/resources and dist/win-ia32-unpacked/resources have different stuff in them. (For example, I put the 64-bit version of the Visual C++ Redistributable package in one of them, and 32-bit in the other.)

I also used 7-Zip to extract the NSIS .exe file, and I only found one set of resources. So I really don't understand what you mean by "Nsis installer contains both archs." Could you explain?

(I used the workaround I mentioned above to solve the problem with producing the artifacts, but I still have a problem with auto-update, because the latest.yml file doesn't make a distinction between ia32 and x64.)

[develar]

You need to build both archs — build --x64 --ia32 --win --publish always to get installer with both archs.

[thomasjm]

Oh okay. That's going to make my installer like 50MB bigger than it needs to be, is it ever going to be possible to do separate installers?

[develar]

is it ever going to be possible to do separate installers?

Well. If will be request. Maybe web installer will suit your needs (#1207)?

[thomasjm]

That looks promising, I will try it out! Thanks

[abalad]

I am configuring my Target to generate the 2 x64 and ia32 versions, but the installer only generates one and does not match the version in the final file.

    "win": {
      "icon": "artifacts/distribution/256x256.png",
      "publisherName": "Temainfo Software, LTDA",
      "artifactName": "${productName} Installer-${arch}-${version}.${ext}",
      "target": [
        {
          "target": "nsis",
          "arch": [
            "x64",
            "ia32"
          ]
        }
      ],

[demurgos]

I prefer to have one installer per arch to provide smaller files. My current workaround is to have two different build commands in my package.json:

  "scripts": {
    "dist:windows-x64": "electron-builder --windows --x64 -c.nsis.artifactName=EternaltwinSetup-x64.exe",
    "dist:windows-ia32": "electron-builder --windows --ia32 -c.nsis.artifactName=EternaltwinSetup-ia32.exe",
  },