Edge: .NET Núcleo RC2

Hola Nick, gracias por la oferta. @lstratman debería poder

@NickStrupat , todo en esta publicación podría cambiar, ya que recién ahora estoy comenzando a ver las secuencias de comandos de Node.js de la pieza CLR. Voy a hacer que la otra mitad de Edge.js funcione con RC2 en los próximos días y, con suerte, tendré algo de tiempo para analizar esto más a fondo. Dicho todo esto, aquí va:

Sorprendentemente, gran parte de la arquitectura para el "scripting Node.js de CLR" existente funcionará bastante bien con .NET Core. Puede echar un vistazo al código existente aquí . Básicamente, se basa en una biblioteca nativa compartida compilada de Node.js (node.dll) que se encuentra en una determinada estructura de directorio, detecta la arquitectura del proceso (x86 frente a x64), llama a la función del kernel LoadLibrary para cargar la biblioteca nativa y luego llama una función de enlace predefinida en esa biblioteca para script de inicio de Edge.js. Ahora, .NET Core en realidad tiene una "compatibilidad con bibliotecas nativas asociadas" increíblemente buena en la que ha administrado un código que se basa en llamadas a código nativo. Le permite incluir versiones de esas bibliotecas nativas para varias arquitecturas y sistemas operativos, ya sea en el paquete NuGet o a través de dependencias para los distintos tiempos de ejecución, y luego .NET Core se encargará de descargar el paquete correcto para su sistema operativo y arquitectura y cargar el biblioteca nativa en la memoria en tiempo de ejecución. Consulte el paquete NuGet nativo para System.IO.Compression para Ubuntu para ver un ejemplo de esto. Por lo tanto, todos los [DllImport] y las llamadas a funciones que tenemos ahora en EdgeJs.cs seguirán funcionando en .NET Core, pero tenemos que trabajar un poco con el paquete NuGet. Entonces, las tareas preliminares incluyen:

• [ ] Definición de un proyecto.json para EdgeJs.cs que incluye todas las dependencias no nativas requeridas para que podamos construir la parte administrada de este proyecto
• [ ] Definición de dos project.json, runtime.win7-x86.Edge.js y runtime.win7-x64.Edge.js (nos preocuparemos por los otros sistemas operativos una vez que Windows funcione), que incluirán node.dll biblioteca compartida nativa
• [ ] Actualice build_double.bat para copiar node.dll en la estructura de directorio correcta para que lo recoja el project.jsons antes mencionado
• [ ] Agregar objetos runtime al proyecto EdgeJs.cs.json para win7-x86 y win7-x64 y objetos dependencies dentro de ellos que apuntan al proyecto nativo antes mencionado.
• [ ] Actualizar [DllIImport] en EdgeJs.cs para node.dll para que la función que busca sea algo más multiplataforma que "#925" (¿quizás solo start ? necesita mirar las funciones exportadas en Dependency Walker o algo así)

Ese es mi volcado de cerebro inicial, siéntase libre de comenzar a mirar cualquiera de estas cosas e informar cualquier cosa que salga mal. Probablemente comenzaré yo mismo más tarde esta semana o principios de la próxima y puedo proporcionar más detalles en ese momento.

Gran lista @lstratman. Con respecto al punto de entrada "#925" (https://github.com/tjanczuk/edge/blob/master/src/double/dotnet/EdgeJs.cs#L51), tenga en cuenta que esto no tiene nada que ver con CLR: este es el punto de entrada a la biblioteca compartida de node.dll, y depende de la versión de Node.js para la que esté compilando. Dado que Node nunca tuvo la intención de ser compatible con el escenario de biblioteca compartida de primera clase, estos puntos de entrada no son estables entre versiones. Podría mejorarse con un pequeño envoltorio o algún código adicional alrededor de node.dll, pero no creo que esto sea necesariamente tan importante en el gran esquema de las cosas.

Necesito un cliente MQTT que admita certificados de cliente para Windows IoI Core (WoA/RP3). Esto es para conectarse a AWS IoT. Actualicé la biblioteca .Net M2Mqtt para que se ejecute en WoA/UWP (¡funciona!), pero preferiría llamar a la biblioteca AWS node.js desde mi aplicación C#. No necesito un paquete nuget para probar. Estoy contento con construir la biblioteca en VS. Me ofrezco como voluntario para probar este escenario y compartir los resultados si el desarrollo de Core está lo suficientemente avanzado para hacerlo.

Publicando una actualización rápida sobre esto. Comencé a jugar un poco con esto hoy y pude obtener la DLL nativa de Node.js referenciada, cargada e invocada con éxito desde .NET Core. Por lo tanto, podemos acelerar el tiempo de ejecución de V8 en un proceso de .NET Core y ejecutar el código Node.js, que obviamente es enorme. El punto conflictivo es que edge_coreclr.node activa el CLR en sí mismo, por lo que cuando se invoca, en realidad crea otro dominio CLR dentro del proceso actual (es una locura que realmente funcione), por lo que no interactúa con la instancia CLR que realmente giró hasta el tiempo de ejecución V8. Básicamente, tengo que descubrir cómo, desde el código nativo, conectar un CLR ya cargado en lugar de activar el CLR desde cero e interactuar con eso. Estoy seguro de que es posible, pero necesito averiguar cómo hacerlo.

Creo que @davidfowl puede proporcionar un indicador sobre cómo obtener una referencia a un dominio de aplicación en ejecución en coreclr, si es posible.

¿Cómo hace esto .NET (edge_nativeclr.node)?

Es un ensamblado C++ de modo mixto, por lo que el compilador VS se encarga de inyectar cualquier vudú que sea necesario para encontrar e interactuar con el CLR. Desafortunadamente, los ensamblajes de modo mixto no son compatibles con .NET Core (por razones técnicas perfectamente buenas y legítimas). Creo que puedo solucionar esto llamando a Marshal.GetFunctionPointerForDelegate() para todas las funciones de delegado requeridas en CoreCLREmbedding y pasando los punteros de función a Node.js. A ver si consigo que funcione mañana.

OK, tengo esto funcionando. La solución es un poco sucia (Marshal.GetFunctionPointerForDelegate(), obtener un puntero inseguro y convertirlo en largo, luego pasarlo como una variable de entorno. Lo sé, lo sé, es horrible), pero es funcional hasta que alguien quiera refactorizarlo. Las pruebas unitarias pasan, excepto la de Unicode, y eso puede tener algo que ver con mi lógica de conversión de cadena .NET string->Node.js subyacente y no tiene nada que ver con la creación de secuencias de comandos de Node.js desde .NET. En este momento, esto es Windows solo hasta que se creen paquetes NuGet en tiempo de ejecución para los otros sistemas operativos: básicamente, esos paquetes NuGet solo contendrán node.dll/node.so/node.dylib y se hará referencia a ellos desde Edge.js project.json en runtimes sección.

Desafortunadamente, tengo un gran proyecto en mi trabajo actual que consumirá la mayor parte de mi tiempo durante el próximo mes o dos, por lo que me alejaré de esto y dejaré el resto del trabajo de implementación a otras partes interesadas. Mi código está en https://github.com/medicomp/edge en la rama double-netcore; @tjanczuk si desea que cree un PR para lo que tengo, hágamelo saber.

Le daré un vistazo.

Ya llevamos un año con este problema y me preguntaba si había alguna actualización. Sería genial albergar Node dentro de un proceso .NETCore.