Unable to find an entry point named "napi_create_platform" in DLL

[itsameshaw]

I've been trying to figure this out for days with different approaches, but I can't find a way for it to work.

var runtime = new NodejsPlatform("C:\\Program Files\\nodejs\\node.exe");

This line to use NodeJS in the C# application fails no matter what I do. Initially, I was trying to connect it to Electron binary, but when it failed I figured they had changed something and that is why. I tried using the official Windows binary - but still to no avail. I even got Node to compile as a shared library to a .dll file. They all result in an error for lacking napi_create_platform. dumpbin shows a bunch of napi_ prefixed functions, but nothing with platform or engine in the name.

I even went into a digital archeologist mode and went through some of Node commit history, but I can't find the napi_create_platform function that would be a connection point to Node. There are only C++ classes. What am I missing?

[jasongin]

The parameter to the NodejsPlatform() constructor should be the path to libnode (DLL on Windows), not the regular Node.js executable.

However, currently this functionality also depends on a PR to Node.js runtime that is not yet merged, which defines napi_create_platform and related entrypoints. I still hope that PR can get merged; I don't know what is holding it up at this point.

When developing and writing the docs for this project, we did not expect that PR to take multiple years. Meanwhile in the last ~6 months we have been much more focused on the reverse scenario (calling .NET from JS). I really would like to get back to embedding JS in .NET apps, as I think there is a lot of interesting work that can be done there. But it all depends on that PR -- until it's merged everyone has to create a private libnode build from the PR which is not easy.

Related issue: #107

[luanmm]

Hey, @jasongin. Just a little contrib here: seems that they are expecting something from your side, reading this comment. To be honest, I couldn't even understand what exactly is, but maybe you or @vmoroz, that are "the brains behind" (as I'm aware of), could help them to finish the merge or something like that.

Disclaimer: I would love to help if I was more aware on how low-level Node code works, but I don't think that is something that I can handle at this time. But if you think I may help in another way, please let me know.

[jasongin]

Yes, @vmoroz and I discussed it and he's planning to work on that PR, as he's much more familiar with the concerns than I am. I did work on that area many years ago but I've been out of the loop for a while.

[vmoroz]

@itsameshaw , @luanmm, I am currently working on the new version of the libnode API and wondering what your high level scenarios for this API are.
I want to make sure that the new API addresses the real life scenarios.

[luanmm]

Hello, @vmoroz! Great news!

In my scenario, I would use node-api-dotnet to give to users "extension points", so they can interact (in a "sandboxed" way) with the platform using Node (or, even better in my case, Deno, when suppported), which is simple and has its large ecosystem considering web projects.

In my case, I don't think there is a direct relation with libnode API, but I was waiting for this patch in libnode so node-api-dotnet library could make use of a pre-installed Node or just use it "embedded" or directly (via Nuget). The big problem nowadays is that I need to compile the forked version of libnode, and this process is not so practical - and have its problems, like needing a specific patched version (and couldn't use any other specific official version that may be of interest).

I don't know if this helps or not, but hope that you make a good progress in this task! It would be a great contribution for sure, enabling node-api-dotnet to work more seamlessy.

Best regards.

[vmoroz]

Thank you, @luanmm , for sharing your scenario and the good words!
I doubt that the shared libnode will be part of the Node.js installation any time soon.
It may unnecessary grow the package size or increase security risks if used with the Node.js executable.
In the best case it can become part of "Node.js developer package" or "Node.js SDK".

Meantime we are going to produce a Nuget package that can work with the node-api-dotnet distribution.

[wasabii]

@vmoroz

I noticed a bunch of Microsoft.JavaScript.LibNode packages up on NuGet now. But the way they are built is a bit hard to understand, and they don't really work. Are they intended for this scenario?

If so, few things.

    <LibNodeOSPlatform Condition="'$(LibNodeOSPlatform)' == '' AND $([MSBuild]::IsOSPlatform('Linux'))">linux</LibNodeOSPlatform>
    <LibNodeOSPlatform Condition="'$(LibNodeOSPlatform)' == '' AND $([MSBuild]::IsOSPlatform('OSX'))">osx</LibNodeOSPlatform>
    <LibNodeOSPlatform Condition="'$(LibNodeOSPlatform)' == '' AND $([MSBuild]::IsOSPlatform('Windows'))">win</LibNodeOSPlatform>

Techniques like this cannot work, since the current build platform is never guarenteed to be the target platform. Instead, two paths need to be taken:

a) .NET CoreCLR related builds: New-style SDKs handle the correct placement of native libraries by including them in the runtimes/native directory of a NuGet package properly.
b) .NET Framework related builds: New-style SDKs do not handle these quite right. In this case, you do need some build scripts to copy the native libraries into the project, and you need the corresponding P/Invoke code to properly probe for the location based on the OS at runtime. With additional allowances for Mono if that's an interest.

Scenario (a) is nice. If you only intend to target CoreCLR projects. You don't need extra build scripts at all. Just to populate the runtimes/native directory in the package and everything is taken care of.

I am the current maintainer of the IKVM project, and we do a lot of similar things.

https://nuget.info/packages/IKVM/8.11.0 for an example