Error "is not Win32 application" when use electron-builder

[zivlakmilos]

SerialPort Version

10.5.0

Node Version

v16.14.2

Electron Version

23.2.0

Platform

Microsoft Windows NT 10.0.19045.0

Architecture

x64

Hardware or chipset of serialport

No response

What steps will reproduce the bug?

Dev machine: Linux zivlak 6.1.1-arch1-1 #1 SMP PREEMPT_DYNAMIC Wed, 21 Dec 2022 22:27:55 +0000 x86_64 GNU/Linux Test machine: Microsoft Windows NT 10.0.19045.

Electron builder version: 23.6.0 Electron builder target: portable x64

• Create electron project
• Import SerialPort
• Build project using electron-builder on Linux machine
• Copy .exe file to windows machine and run it

What happens?

Uncaught Error: \\?\C:\Users\ZI\AppData\Local\Temp\3c0cfb43-c0d6-41df-8ecf-ce6623539fad.tmp.node is not a valid Win32 application.
\\?\C:\Users\ZI\AppData\Local\Temp\3c0cfb43-c0d6-41df-8ecf-ce6623539fad.tmp.node
    at process.func [as dlopen] (node:electron/js2c/asar_bundle:2:1822)
    at Module._extensions..node (node:internal/modules/cjs/loader:1259:18)
    at Object.func [as .node] (node:electron/js2c/asar_bundle:2:2049)
    at Module.load (node:internal/modules/cjs/loader:1044:32)
    at Module._load (node:internal/modules/cjs/loader:885:12)
    at f._load (node:electron/js2c/asar_bundle:2:13330)
    at o._load (node:electron/js2c/renderer_init:2:3109)
    at Module.require (node:internal/modules/cjs/loader:1068:19)
    at require (node:internal/modules/cjs/helpers:103:18)
    at load (C:\Users\ZI\AppData\Local\Temp\2O4lZlaiKxPE0OCBtsho17I24ti\resources\app.asar\node_modules\node-gyp-build\node-gyp-build.js:22:10)

What should have happened?

Program should list all available ports on machine, but it's crash on importing SerialPort module.

Additional information

No response

[ddiesenreither]

I am facing the same error - is there a solution already?

[noe2505]

Solution is to build in a windows machine. Had the same issue developing in a Mac, the build in a Win VM ran with no issue.

[Marlonzao]

Solution is to build in a windows machine. Had the same issue developing in a Mac, the build in a Win VM ran with no issue.

Not a good solution for automated builds...

[noe2505]

Solution is to build in a windows machine. Had the same issue developing in a Mac, the build in a Win VM ran with no issue.

Not a good solution for automated builds...

We can suppose you got a better/working one, illuminate us!

[Marlonzao]

Solution is to build in a windows machine. Had the same issue developing in a Mac, the build in a Win VM ran with no issue.

Not a good solution for automated builds...

We can suppose you got a better/working one, illuminate us!

Not really, stumbled on this today and also stuck on it, testing everything I can

[GazHank]

I'm afraid that while the error code is very similar, the closed issue you reference is very unlikely to be related as the root cause of that was broken inbound dependency which was entirely stripped out as part of serialport v10. So I don't think that will allow us to trace the problem.

In trying to replicate your issue I think this comes down to an electron-builder issue which affect cross build for both Mac and Linux targeting windows.

With a very simple project (based on the electron-serialport example) compiling on Linux (ubuntu) and Windows I experience the same problems as described in https://github.com/electron-userland/electron-builder/issues/7574

Even before the application is packaged, the unpackaged output from electron-builder is inconsistent. On Windows it places all of the required data in the app.asar, while on Linux it creates an app.asar.unpacked folder for the serialport package. According to the docs @ https://www.electron.build/generated/platformspecificbuildoptions this seems to be due to it "automatically detecting" that it needs to be unpacked, but as we can see based on the working Windows compile this is not the case, so the detection routing is what seems to be at fault.

I'll continue to dig, but I'm not sure if I will find a fix quickly.

In the meantime I would echo the suggestion to build on a windows instance if you can. Per your comment about concerns with automated builds, one option to enable to build via your Linux machine would be to use Windows in a VM or container.

[Marlonzao]

Thanks for the reply, I too noted this app.asar.unpacked folder, I'll be analyzing it too.

[zivlakmilos]

Solution is to build in a windows machine. Had the same issue developing in a Mac, the build in a Win VM ran with no issue.

Only reason for using electron to me is option to quickly build project on Linux for windows. If I need windows I would prefer any other native technology.

[GazHank]

I'll continue to investigate the issue with the cross build via electron-builder, but will keep those investigations in the electron-builder repository to minimise confusion (check out that issue if you want to help with the investigations).

While those investigations progress I might see if the process is any better in electron forge or if it suffers from the same problems

[GazHank]

Please refer to https://github.com/electron-userland/electron-builder/issues/7574 for potential fix / workaround

If this proves to work for people (and not break anything else) then I'll see about adding it into the documentation website

[GazHank]

Thanks to the electron-builder team this should now be fixed in their new version 24.5.1

[reconbot]

@GazHank riveting investigation!

[Marlonzao]

Thanks to the electron-builder team this should now be fixed in their new version 24.5.1

Hello @GazHank sorry to be bothering you again but this error is still happening to me. I've updated my electron-builder to 24.5.2, but my electron is still version 17. I have some screenshots of my ci running the build, but I could't determine why only updating electron-builder didn't fix it.

What test did you ran?

[pjreed]

I know this is an old issue, but I just ran into it and it's still not working for me. I'm using electron 28.0.0, electron-builder 24.9.1, and serialport 12.0.0, so I have up-to-date versions of everything.

When I try to build it in Linux, the build log looks like it should be building @serialport/bindings-cpp for Windows:

  • electron-builder  version=24.9.1 os=6.5.6-76060506-generic
  • loaded configuration  file=/home/preed/src/dashboard/electron-builder.json5
  • writing effective config  file=release/1.0.0/builder-effective-config.yaml
  • rebuilding native dependencies  dependencies=@serialport/bindings-cpp@12.0.1 platform=win32 arch=x64
  • rebuilding native dependency  name=@serialport/bindings-cpp version=12.0.1
  • packaging       platform=win32 arch=x64 electron=28.0.0 appOutDir=release/1.0.0/win-unpacked
  • building        target=portable file=release/1.0.0/dashboard_1.0.0.exe archs=x64
Done in 54.13s.

But the generated binary is in ELF format:

$ file ./release/1.0.0/win-unpacked/resources/app.asar.unpacked/node_modules/@serialport/bindings-cpp/build/Release/bindings.node
./release/1.0.0/win-unpacked/resources/app.asar.unpacked/node_modules/@serialport/bindings-cpp/build/Release/bindings.node: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=67c079f9038b36c6f27cd38ef8f48cccc5f5ca3d, not stripped

[etorres1193]

Hey @pjreed I had the same issue. I set buildDependenciesFromSource to true in the build options and now it works.

[pjreed]

Hey @pjreed I had the same issue. I set buildDependenciesFromSource to true in the build options and now it works.

That doesn't work for me, and I'm not sure how it could possibly work. When setting that, I see this in the output:

  • skipped dependencies rebuild  reason=platform is different and buildDependenciesFromSource is set to true

app-builder-lib appears to be hard-coded to fail if that flag is set but your build platform does not match your build target; see https://github.com/electron-userland/electron-builder/blob/master/packages/app-builder-lib/src/packager.ts#L522. Mine does not since I'm using electron-builder on a Linux machine to build a Windows target.

[etorres1193]

I'm using docker (electronuserland/builder:18-wine-mono) and targeting to windows.

My build command is:

electron-builder --config electron-builder-dev.yml --win --x64

electron-builder-dev.yml

productName: 'My App'
directories:
  output: out

buildDependenciesFromSource: true

win:
  target:
    - nsis
    - zip
  icon: 'resources/my-icon.ico'
  publish:
    provider: 'generic'
    url: 'localhost'

nsis:
  artifactName: '${name}-${version}.${ext}'

Without the buildDependenciesFromSource: true property, I had the same issue mentioned above.

DockerFile

FROM electronuserland/builder:18-wine-mono
ENV WINEARCH=win64
ENV WINEPREFIX=/root/.wine64

COPY . .

npm install && electron-builder --config electron-builder-dev.yml --win --x64

[TreeOfLearning]

Hey @pjreed I had the same issue. I set buildDependenciesFromSource to true in the build options and now it works.

That doesn't work for me, and I'm not sure how it could possibly work. When setting that, I see this in the output:

  • skipped dependencies rebuild  reason=platform is different and buildDependenciesFromSource is set to true

app-builder-lib appears to be hard-coded to fail if that flag is set but your build platform does not match your build target; see https://github.com/electron-userland/electron-builder/blob/master/packages/app-builder-lib/src/packager.ts#L522. Mine does not since I'm using electron-builder on a Linux machine to build a Windows target.

Also experiencing this. Did you find a solution?

[baozouai]

I know this is an old issue, but I just ran into it and it's still not working for me. I'm using electron 28.0.0, electron-builder 24.9.1, and serialport 12.0.0, so I have up-to-date versions of everything.

When I try to build it in Linux, the build log looks like it should be building @serialport/bindings-cpp for Windows:

  • electron-builder  version=24.9.1 os=6.5.6-76060506-generic
  • loaded configuration  file=/home/preed/src/dashboard/electron-builder.json5
  • writing effective config  file=release/1.0.0/builder-effective-config.yaml
  • rebuilding native dependencies  dependencies=@serialport/bindings-cpp@12.0.1 platform=win32 arch=x64
  • rebuilding native dependency  name=@serialport/bindings-cpp version=12.0.1
  • packaging       platform=win32 arch=x64 electron=28.0.0 appOutDir=release/1.0.0/win-unpacked
  • building        target=portable file=release/1.0.0/dashboard_1.0.0.exe archs=x64
Done in 54.13s.

But the generated binary is in ELF format:

$ file ./release/1.0.0/win-unpacked/resources/app.asar.unpacked/node_modules/@serialport/bindings-cpp/build/Release/bindings.node
./release/1.0.0/win-unpacked/resources/app.asar.unpacked/node_modules/@serialport/bindings-cpp/build/Release/bindings.node: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=67c079f9038b36c6f27cd38ef8f48cccc5f5ca3d, not stripped

hi~ Did you find a solution?

[pjreed]

Unfortunately, just for the record, I have still not found a solution other than "build it in a Windows VM"

[MuxBH28]

Unfortunately, just for the record, I have still not found a solution other than "build it in a Windows VM"

Hello mate, I still have the issues even in Windows 10 VM. While on Linux, the app will be built, but I would get the error when trying to run an app on Windows:

While trying to build the app in windows, I get this: `C:\Users\Win\Desktop\1.2.5>npm run build

market-app@1.2.5 build electron-builder --win

• electron-builder version=24.13.3 os=10.0.19045 • loaded configuration file=package.json ("build" field) • @electron/rebuild not required if you use electron-builder, please consider to remove excess dependency from devDependencies

To ensure your native dependencies are always matched electron version, simply add script "postinstall": "electron-builder install-app-deps" to yourpackage.json` • writing effective config file=dist\builder-effective-config.yaml • rebuilding native dependencies dependencies=@serialport/bindings-cpp@12.0.1 platform=win32 arch=x64 ⨯ cannot execute cause=exit status 1 errorOut=npm error code 1 npm error path C:\Users\Win\Desktop\1.2.5\node_modules\@serialport\bindings-cpp npm error command failed npm error command C:\Windows\system32\cmd.exe /d /s /c node-gyp-build npm error node:internal/child_process:421 npm error throw new ErrnoException(err, 'spawn'); npm error ^ npm error npm error Error: spawn EINVAL npm error at ChildProcess.spawn (node:internal/child_process:421:11) npm error at Object.spawn (node:child_process:761:9) npm error at build (C:\Users\Win\Desktop\1.2.5\node_modules\@serialport\bindings-cpp\node_modules\node-gyp-build\bin.js:29:8) npm error at preinstall (C:\Users\Win\Desktop\1.2.5\node_modules\@serialport\bindings-cpp\node_modules\node-gyp-build\bin.js:38:32) npm error at Object. (C:\Users\Win\Desktop\1.2.5\node_modules\@serialport\bindings-cpp\node_modules\node-gyp-build\bin.js:15:3) npm error at Module._compile (node:internal/modules/cjs/loader:1546:14) npm error at Module._extensions..js (node:internal/modules/cjs/loader:1691:10) npm error at Module.load (node:internal/modules/cjs/loader:1317:32) npm error at Module._load (node:internal/modules/cjs/loader:1127:12) npm error at TracingChannel.traceSync (node:diagnostics_channel:315:14) { npm error errno: -4071, npm error code: 'EINVAL', npm error syscall: 'spawn' npm error } npm error npm error Node.js v22.6.0 npm error A complete log of this run can be found in: C:\Users\Win\AppData\Local\npm-cache_logs\2024-08-19T20_47_08_788Z-debug-0.log

                command='C:\Program Files\nodejs\node.exe' 'C:\Program Files\nodejs\node_modules\npm\bin\npm-cli.js' rebuild @serialport/bindings-cpp@12.0.1
                workingDir=

C:\Users\Win\Desktop\1.2.5>`