Repository navigation
Add support for the current version of Node #472
Description
I tried using the latest version of "libnode.dll" but it says that there's no entrypoint node_embedding_platform_create() inside of it
Could you add support to new node versions? (The one I was trying is "v25.6.1")
Or am I doing something wrong on my side? Is there any workaround?
Activity
wasabii commentedon Oct 4, 2026
Vladimir Morozov (@vmoroz) Mind posting a status update on this one? Just whats the current thinking. Any progress, or even attempts? Did the changes you need make it upstream, etc?
I ask because I've been working on this: https://github.com/alethic/Alethic.Node
wasabii commentedon Oct 5, 2026
Vladimir Morozov (@vmoroz) Following up on my own question, since I went ahead and took a crack at it.
As far as I can tell the C embedding API PR (nodejs/node#54660) got closed without being merged, so the patched libnode builds this repo depends on are kind of a dead end. They're stuck on Node 20, which is out of support now. So instead of waiting on that I reworked the hosting side so it doesn't need any Node patches at all. Three pieces:
1. Our own libnode build. alethic/libnode-dotnet builds stock, unpatched Node as a shared library. Node is just a git submodule pinned to an upstream release tag (v26.10.0 right now), built with Node's own build scripts in GitHub Actions for Windows, Linux and macOS on x64 and arm64 (workflow). The build is cached, so Node only gets rebuilt when the submodule moves.
2. A small C shim, node-dotnet. Node already has a public embedding API, it's just C++ (node.h), so you can't P/Invoke it. node-dotnet is a thin C wrapper over that, plus the handful of V8 scope types you need. One C function per C++ function, no logic of its own. The header is basically the whole story. It's built right next to libnode with the same compiler and ships in the same package, so the C++ ABI always lines up. I used Claude to generate a good chunk of the shim code.
3. Updated .NET code. On a branch of my fork I rewrote the embedding layer on top of the shim (P/Invoke surface). The only real trick is getting a
napi_env, since Node has no public way to hand one to an embedder. So we register a linked binding before the environment loads and have the bootstrap script callprocess._linkedBinding(), and Node hands us a realnapi_env(here). So as far as Node is concerned, the .NET side is just another Node-API addon, linked into the process instead of loaded from a .node file. From there everything is plain Node-API, same as it always was. Full diff against main is here.Everything this uses is already public in Node: node.h plus Node-API. Nothing has to land upstream and there are no patches to carry around. Upgrading Node is moving the submodule and rebuilding. If node.h changes between versions, you just update the shim to match.
I only care about hosting Node from .NET right now. I'm not doing anything with the other direction, hosting .NET inside Node, so on my branch I turned all that off: the native AOT module, the npm packages, DotNetHost and the Generator. The code's still there, I just haven't built or tested it against any of this, and CI on my branch only runs the embedding tests. The parts I have tested work great. The existing embedding tests pass unchanged on Node 26 on Windows, on both .NET 10 and .NET Framework. Linux and macOS build, but I haven't finished checking them. And the packages are under our own names (
Alethic.LibNode,Alethic.NodeApi) on our GitHub Packages feed, not nuget.org.Anyway, it's all there. Take it if you want it. I'd rather not be the one maintaining this.