Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Path to Microsoft.JavaScript.NodeApi.DotNetHost.dll in electron binary is incorrect #332

Open
sumeet-singh04 opened this issue Jul 22, 2024 · 4 comments
Labels
electron enhancement New feature or request
Milestone

Comments

@sumeet-singh04
Copy link

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.

let managedHostPath = __dirname + `/${targetFramework}/${assemblyName}.DotNetHost.dll`
  managedHostPath = managedHostPath.indexOf('app.asar.unpacked') < 0 ? 
    managedHostPath.replace('app.asar', 'app.asar.unpacked') : managedHostPath;
@jasongin
Copy link
Member

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?

@jasongin
Copy link
Member

Apparently it is a common problem, and is the reason the hazardous package was created. However that reportedly has problems with newer Electron builds.

@jasongin
Copy link
Member

A potential solution here could be to offer a more general way to customize the initialization. Something like this:

const initDotnet = require('node-api-dotnet/init');
const dotnet = initDotnet({
    targetFramework: 'net8.0',
    binDir: 'path/to/asar.unpacked',
});

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.

@jasongin jasongin added the enhancement New feature or request label Aug 15, 2024
@jasongin jasongin added this to the Backlog milestone Aug 15, 2024
@sumeet-singh04
Copy link
Author

A potential solution here could be to offer a more general way to customize the initialization. Something like this:

const initDotnet = require('node-api-dotnet/init');
const dotnet = initDotnet({
    targetFramework: 'net8.0',
    binDir: 'path/to/asar.unpacked',
});

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
electron enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants