1

We're trying to build our Electron app under a different name, with a different appId so that we can run it alongside our original app - but it always triggers Electrons 'second-instance' - at least on Windows where I'm testing.

What do we need to do to make Electron that these are two entirely separate applications?

Slbox
  • 10,957
  • 15
  • 54
  • 106

2 Answers2

1

We had the same problem using electron-packager. Changing the executable name via appname is not sufficient but changing the name in package.json also did it.

We were using dot-json from our build system after packaging to change it. See this answer about using dot-json from npm.

For the question about what is used for identity: As far as i could determine electron uses a lockfile in %USER_DATA_DIR%\%APPNAME_FROM_PROJECT_JSON%\lockfile. On my machine for an app called electron-shell it becomes C:\Users\UserName\AppData\Roaming\electron-shell\lockfile. It is possible to look this up using the Sysinternals Process-Explorer.

sanosdole
  • 2,469
  • 16
  • 18
  • Hey @sanosdole Thanks for your answer! I tried that but that didn't do it for me with `electron-builder` on Windows even though you'd think it would. Can I ask, what OS did you test this on? – Slbox Nov 20 '20 at 20:36
  • 1
    We tested only on Windows with Electron 10.1.1.We changed the `name` in `resources\app\package.json` in the packaged application after packaging. – sanosdole Nov 22 '20 at 06:54
  • 1
    I added a description on how electron determines identity for `requestSingleInstanceLock` – sanosdole Nov 22 '20 at 07:15
  • Great info, thanks for sharing! That said, I think it's highly inadvisable to use your method of changing it _after_ packaging, except in development circumstances. – Slbox Nov 22 '20 at 20:24
  • 1
    We could change it directly in the package.json before packaging, but we are using the same project.json for different application brandings. So we would need to change it back to a general name after packaging to prevent source control from going wild. That is what we' ll do if the packaging gets more complex like using ASAR archives. Of course if the tooling would support this during packaging it would be nicer. – sanosdole Nov 23 '20 at 11:14
0

What we did to resolve this was set the nsis.guid ourselves to predefined UUIDv5 string.

You can repackage an application without having it trigger 'second-instance' by manually setting the GUID - at least on Windows.

Changing the appId or name should change this according to the docs. It does change the GUID, as confirmed via the Windows registry (regedit), but it wasn't enough.

Slbox
  • 10,957
  • 15
  • 54
  • 106