You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When electron apps are packaged with ASAR enabled, all binaries get placed inside app.asar archive, but when accessed those need to be accessed via app.asar.unpacked directory if the node module does not use path or fs to resolve file names.
For now I am doing the below inside init.js to get things working on my end, but it would be nice to have this handled within the node-api-dotnet library.
I'm not sure about putting this kind of electron-specific logic in the library. Why isn't this a problem for any other npm package that loads binaries?
Apparently it is a common problem, and is the reason the hazardous package was created. However that reportedly has problems with newer Electron builds.
The optional binDir would be used instead of __dirname as the base path for locating the .NET hosting binaries.
Once initialized, any other calls to require('node-api-dotnet') return the existing already-initialized instance.
that or give the ability to pass a path resolution callback method, which the consuming application can use to provide logic to manipulate the binary paths to the exact location. My reasoning behind this that electron applications might not be packaged as asar's always. It's configurable.
When electron apps are packaged with ASAR enabled, all binaries get placed inside
app.asar
archive, but when accessed those need to be accessed viaapp.asar.unpacked
directory if the node module does not usepath
orfs
to resolve file names.For now I am doing the below inside
init.js
to get things working on my end, but it would be nice to have this handled within thenode-api-dotnet
library.The text was updated successfully, but these errors were encountered: