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

[sumeet-singh04]

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]

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]

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]

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.

[sumeet-singh04]

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.

[dhimmel]

We hit this in our Electron app (node-api-dotnet 0.9.19, Electron 40). The error manifests as Arg_COMException when loading net472.

Building on Sumeet Singh (@sumeet-singh04)'s solution, we used patch-package to patch init.js automatically on npm install:

  // Add after rid definition
  function fixAsarPath(p) {
    if (p.includes('app.asar') && !p.includes('app.asar.unpacked')) {
      return p.replace('app.asar', 'app.asar.unpacked');
    }
    return p;
  }

  // Then wrap managedHostPath
  const managedHostPath = fixAsarPath(__dirname + `/${targetFramework}/${assemblyName}.DotNetHost.dll`)

You also need asarUnpack in electron-builder config to actually extract the files:

  asarUnpack:
    - node_modules/node-api-dotnet

Hoping not to rely on patching forever.