español - ¿Hay implementaciones.NET CLR/DLR de ECMAScript?
ecmascript 6 (9)
V8.NET
Este es probablemente el mejor que he encontrado hasta ahora.
https://v8dotnet.codeplex.com/documentation
Además, se ha construido desde el principio con un puerto Mono en mente. Le da control total sobre la potencia del motor V8 desde el código administrado.
¿Alguien sabe de implementaciones reales (i .. no vaporware) de ECMAScript dirigidas a .NET CLR / DLR ? Idealmente, algo así como lo que Rhino es para Java . Un puerto sólido de Rhino ejecutándose en .NET Framework / Mono Framework sería perfecto.
Solo he visto un puñado de proyectos mencionados, pero nunca he visto salir a la luz ni, en realidad, nada de lo que haya podido ejecutar. Esto es lo que ya sé:
MSScriptControl ActiveX Control : AFAIK, esta fue la última implementación verdadera compatible con ECMAScript de Microsoft (ejecuta JScript 5.7). Me he integrado con MSScriptControl, pero no considero la interoperabilidad COM como una respuesta a esta pregunta. x64 es un asesino para esta opción.
JScript.NET : no cuento JScript.NET porque nunca podría analizar correctamente ninguno de mis scripts reales. Parece tener problemas con los cierres.
Managed JScript : Suena como lo que quiero, pero parece estar muerto en el agua. Fue una implementación de ejemplo importante para el DLR, pero luego se enredó con SilverLight y parece haberse desvanecido como una prioridad desde 2007. Las fuentes confiables sobre el estado de esto serían útiles.
MyJScript : construido como una implementación tutorial para el DLR. Alguien sabe cuán completa es esta implementación?
Jint : intérprete de JavaScript para .NET.
Todavía no es compatible con Currying otry
-catch
-finally
.RemObjects Script para .NET : un contendiente interesante que aún está en proceso. Estoy confundido por su comercialización de lo que será en realidad, pero parece que finalmente podría ser un ajuste. Si alguien sabe más al respecto también sería útil.
V8 para .NET : esto sería genial si alguien portase V8 a .NET. Por lo que yo sé, no hay un gran esfuerzo en esto tampoco. El enlace es una idea para llamar desde un contenedor de C ++ administrado.
Para el fondo, quiero poder ejecutar JavaScript desde .NET; es decir, cargar un conjunto de scripts en contexto y llamar a ese contexto y recuperar los resultados de la ejecución. Actualmente salta a través de aros para usar MSScriptControl a través de engorroso COM Interop. La incoherencia de COM hace que sea realmente difícil para la implementación y garantizar una ejecución coherente.
Me gustaría poder ejecutar arneses de prueba de JavaScript razonablemente complejos desde .NET. Esto no es para crear macros de usuario o simples scripts pequeños; Necesito un entorno de JavaScript real como Rhino. Si la implementación se ejecutara sobre el CLR (en lugar de COM), esto realmente ayudaría con algunos de los problemas actuales.
Actualmente, he modificado una versión de EcmaScript.NET dentro de mi puerto YUICompressor.NET (proyecto).
Si agarras el código fuente desde aquí , he incluido mi código modificado en el proyecto, al que puedes hacer referencia. Esta es la única fuente de código que he encontrado en .NET que puede manejar el análisis de javascript, del lado del servidor.
Lamentablemente, no puedo recordar cómo finalmente lo encontré. Fue un proceso difícil, debo admitirlo. Creo que encontré algunas referencias de páginas de desarrollo de Mozilla en algún lugar sobre Rhino (el código de Java) que me llevaron a encontrar esa impregnación de C # .NET.
Tuve que modificarlo ligeramente para sincronizarlo con algunos cambios que los chicos de YUI Compressor le hicieron a su rama de código. Entonces la rama modificada que tengo puede no ser la mejor ... pero es la más cercana que he visto a la rama original de Java.
El código original de c # para EcmaScript.NET no se ha tocado desde 2007 ... al menos para la página de descargas.
Tal vez esto podría ayudar?
HTH.
Debería probar Javascript .NET ( http://javascriptdotnet.codeplex.com/ ) en Codeplex. Envolvieron v8 con C ++ administrado y luego puede usar esta biblioteca con una aplicación .NET y funciona como un amuleto. La fuente abierta ofrece algunas características bastante buenas si me preguntas.
Aclamaciones.
Nadie ha mencionado jurásico http://jurassic.codeplex.com/ No sé qué tan bueno es en general (rendimiento, usabilidad, etc.) pero al menos analiza scripts bastante complejos (otras implementaciones no) y es compatible con ECMAScript 5 especulación. Acabo de agregar el enlace aquí para referencia.
Nadie menciona ClearScript, entonces ClearScript .
No es una implementación; es un contenedor de interoperabilidad que admite V8, JScript y VBScript, con una API realmente agradable para llamar desde el código .NET.
Código de ejemplo de la página CodePlex:
using System;
using Microsoft.ClearScript;
using Microsoft.ClearScript.V8;
// create a script engine
using (var engine = new V8ScriptEngine())
{
// expose a host type
engine.AddHostType("Console", typeof(Console));
engine.Execute("Console.WriteLine(''{0} is an interesting number.'', Math.PI)");
// expose a host object
engine.AddHostObject("random", new Random());
engine.Execute("Console.WriteLine(random.NextDouble())");
// expose entire assemblies
engine.AddHostObject("lib", new HostTypeCollection("mscorlib", "System.Core"));
engine.Execute("Console.WriteLine(lib.System.DateTime.Now)");
// create a host object from script
engine.Execute(@"
birthday = new lib.System.DateTime(2007, 5, 22);
Console.WriteLine(birthday.ToLongDateString());
");
// use a generic class from script
engine.Execute(@"
Dictionary = lib.System.Collections.Generic.Dictionary;
dict = new Dictionary(lib.System.String, lib.System.Int32);
dict.Add(''foo'', 123);
");
// call a host method with an output parameter
engine.AddHostObject("host", new HostFunctions());
engine.Execute(@"
intVar = host.newVar(lib.System.Int32);
found = dict.TryGetValue(''foo'', intVar.out);
Console.WriteLine(''{0} {1}'', found, intVar);
");
// create and populate a host array
engine.Execute(@"
numbers = host.newArr(lib.System.Int32, 20);
for (var i = 0; i < numbers.Length; i++) { numbers[i] = i; }
Console.WriteLine(lib.System.String.Join('', '', numbers));
");
// create a script delegate
engine.Execute(@"
Filter = lib.System.Func(lib.System.Int32, lib.System.Boolean);
oddFilter = new Filter(function(value) {
return (value & 1) ? true : false;
});
");
// use LINQ from script
engine.Execute(@"
oddNumbers = numbers.Where(oddFilter);
Console.WriteLine(lib.System.String.Join('', '', oddNumbers));
");
// call a script function
engine.Execute("function print(x) { Console.WriteLine(x); }");
engine.Script.print(DateTime.Now.DayOfWeek);
// examine a script object
engine.Execute("person = { name: ''Fred'', age: 5 }");
Console.WriteLine(engine.Script.person.name);
}
Prefiero JINT en lugar de los demás.
JINT puede ser lento, pero es fácil depurar e interactuar con sus propias clases de .NET. (Es difícil establecer atributos [ComVisile]
cada vez para jscript.dll, etc.).
En términos de enhebrado, JINT y Jurásico funcionan como esperaba. Para poder trabajar con el motor JScript o Google V8, debe prestar atención al problema de enhebrado de UI.
Sin embargo, JINT está desactualizado en algún aspecto, porque tengo problemas para compilar JQuery 1.5 o posterior.
Espero que Jurassic pueda eliminar su límite para incluir su propia clase para trabajar creando ''AllowBob''sCLRClass=true''
.
Tengo que volver a escribir toda la clase. Es difícil...
Puede usar Jscript.net y realmente funcionará con código javascript arbitrario; Solo tiene que desactivar el "modo rápido" compilando con jsc /fast- bar.js
No he probado esto; Lo noté al leer esta publicación y pensé que sería otra solución razonable. MSDN tiene los documentos para esta opción y cuáles son las limitaciones si no la usa .
Todavía bastante vivo:
- http://jurassic.codeplex.com/ (Tuvo un compromiso en el último año)
- Jint (actualmente recibe solicitudes de extracción)
Otros proyectos, en su mayoría muertos:
- IronJS : una implementación JS alojada en DLR; IronJS Google Group . (El último compromiso fue en 2013, la última actualización del blog en 2012.)
- Managed JScript : Murió en la vid .
- MyJScript: mencionado en la publicación original, para aquellos que quieren más información, hay un artículo: crea tu propio idioma encima del DLR .
- MonoJS : Mono tuvo una implementación de JScript.Net, pero dejaron de molestar.
Método loco:
- Rhino sobre IKVM (mencionado en los comentarios, pero aquí hay un enlace para obtener más información sobre cómo hacerlo).