ECMAScript 是否有任何 .NET CLR/DLR 实现?
有谁知道针对 .NET CLR/DLR 的 ECMAScript 的真实(即非蒸汽软件)实现吗? 理想情况下类似于Rhino for Java。 在 .NET Framework / Mono Framework 上运行的 Rhino 的可靠移植将是完美的。
我只看到了提到的少数项目,但从未见过任何项目被曝光,或者实际上任何我曾经能够运行脚本的项目。 这是我已经知道的:
MSScriptControl ActiveX Control:据我所知,这是 Microsoft 最后一个真正的 ECMAScript 兼容实现(运行 JScript 5.7)。 我已经与 MSScriptControl 集成,但不认为 COM 互操作是这个问题的答案。 x64 是此选项的杀手。
JScript.NET:我不要算 JScript.NET,因为它永远无法成功解析我的任何真实脚本。 似乎在关闭方面遇到了麻烦。
托管 JScript:听起来像我想要的,但是它似乎已经死在水里了。 它是 DLR 的一个主要示例实现,但后来与 SilverLight 纠缠在一起,并且自 2007 年以来似乎已经不再是优先事项。有关其状态的可信来源会有所帮助。
MyJScript:作为 DLR 的教程实现而构建。 有人知道这个实现有多完整吗?
Jint:.NET 的 JavaScript 解释器。
尚不支持 Currying 或try
-catch
-finally
。< a href="http://www.remobjects.com/roscript.aspx" rel="noreferrer">RemObjects Script for .NET:一个有趣的竞争者仍在开发中。 我对他们的营销方式感到困惑,不知道它到底是什么,但听起来它最终可能会合适。 如果有人了解更多信息,也会很有帮助。
V8 for .NET:如果有人将 V8 移植到 .NET,那就太好了。 据我所知,在这方面也没有付出很大的努力。 该链接指向从托管 C++ 包装器调用它的想法。
作为背景,我希望能够从 .NET 中执行 JavaScript; 即,将一组脚本加载到上下文中并调用该上下文并检索执行结果。 目前,我通过繁琐的 COM Interop 来使用 MSScriptControl。 COM 的不一致性使得部署和确保一致执行变得非常困难。
我希望能够从 .NET 中执行相当复杂的 JavaScript 测试工具。 这不适用于创建用户宏或简单的小脚本; 我需要一个像 Rhino 这样的真正的 JavaScript 环境。 如果实现运行在 CLR(而不是 COM)之上,这确实有助于解决当前的一些问题。
Does anyone know of real (i.. no vaporware) implementations of ECMAScript targeting the .NET CLR/DLR? Ideally something like what Rhino is for Java. A solid port of Rhino running on .NET Framework / Mono Framework would be perfect.
I've only seen a handful of projects mentioned but never seen any come to light or in reality anything that I've ever been able to run script on. Here's what I know about already:
MSScriptControl ActiveX Control: AFAIK, this was Microsoft's last real ECMAScript-compliant implementaiton (runs JScript 5.7). I've integrated with MSScriptControl but don't consider COM interop to be an answer to this question. x64 is a killer for this option.
JScript.NET: I don't count JScript.NET as it could never successfully parse any of my real scripts. It seems to have trouble with closures.
Managed JScript: Sounds like what I want but it appears to be dead in the water. It was a major example implementation for the DLR but then got entangled with SilverLight and seems to have faded as a priority since 2007. Creditable sources on the status of this would be helpful.
MyJScript: Built as a tutorial implementation for the DLR. Anyone know how complete of an implementation this is?
Jint: JavaScript interpreter for .NET.
Doesn't as of yet support Currying ortry
-catch
-finally
.RemObjects Script for .NET: An interesting contender still in the works. I'm confused by their marketing as to what it will actually be, but it sounds like it might eventually be a fit. If anyone knows more about it that would be helpful as well.
V8 for .NET: This would be great if someone ported V8 to .NET. As far as I know there isn't a large effort around this either. The link is to an idea for calling into it from a managed C++ wrapper.
For background, I want to be able to execute JavaScript from within .NET; i.e. load up a set of scripts into context and call into that context and retrieve the execution results. Currently I jump through hoops to use MSScriptControl via cumbersome COM Interop. The inconsistency of COM makes it really tough for deployment and ensuring consistent execution.
I'd like to be able to execute reasonably complex JavaScript test harnesses from within .NET. This isn't for creating user macros or simple tiny scripts; I need a real JavaScript environment like Rhino. If the implementation was running on top of the CLR (rather than COM) this would really help with some of the current issues.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(9)
目前,我已经修改了 EcmaScript.NET 的一个版本="http://yuicompressor.codeplex.com/" rel="noreferrer">YUICompressor.NET 端口(项目)。
如果您从此处获取源代码,我已将修改后的代码包含在项目中,你可以参考一下。 这是我在 .NET 中找到的唯一可以在服务器端处理解析 javascript 的代码源。
不幸的是,我不记得我最后是如何找到它的。 我必须承认,这是一个艰难的过程。 我想我在 Mozilla 开发页面上找到了一些关于 Rhino(java 代码)的参考资料,这让我找到了 C# .NET 实现。
我必须稍微修改它以与 YUI Compressor 人员对其代码分支所做的一些更改同步。 所以我修改后的分支可能不是最好的..但它是我见过的最接近原始 Java 分支的。
自 2007 年以来,EcmaScript.NET 的原始 C# 代码就没有被触及过……至少对于下载页面而言是这样。
也许这可能有帮助?
HTH。
Currently, I've modified a version of the EcmaScript.NET inside my YUICompressor.NET port (project).
If you grab the source code from here, I've included my modified code in the project, which you can reference. This is the only source of code i've found in .NET which can handle parsing javascript, server side.
Unfortunately, I can't remember how I finally found it. It was a tough process, I must admit. I think i found some references Mozilla dev pages somewhere about Rhino (the java code) which led me to finding that C# .NET implimentation.
I had to modify it slighty to sync up with some changes the YUI Compressor guys did to their code branch. So the modified branch I have might not be the best .. but it's the closest I've seen to the original Java branch.
The original c# code for EcmaScript.NET hasn't been touched since 2007 ... at least for the downloads page.
Maybe this might help??
HTH.
仍然大致存在:
其他项目,大多已经死亡:
疯狂方法:
Still Roughly alive:
Other Projects, Mostly Dead:
Crazy Method:
没有人提到过侏罗纪 http://jurassic.codeplex.com/
我不知道它总体上有多好(性能、可用性等),但至少它可以解析相当复杂的脚本(其他实现则不能)并且它支持 ECMAScript 5 规范。 我只是在这里添加链接以供参考。
Nobody has mentioned jurassic http://jurassic.codeplex.com/
I do not know how good it is in general (performance, usability, etc) but at least it parses pretty complex scripts (other implementations do not) and it supports ECMAScript 5 spec. I just add the link here for reference.
没有人提到 ClearScript,所以 ClearScript。
这不是一个实现;而是一个实现。 它是一个互操作包装器,支持 V8、JScript 和 VBScript,并具有非常好的 API 可以从 .NET 代码调用它们。
CodePlex 页面的示例代码:
Nobody's mentioned ClearScript, so ClearScript.
It's not an implementation; it's an interop wrapper that supports V8, JScript and VBScript, with a really nice API to call into them from .NET code.
Example code from the CodePlex page:
你可以看看 Jint (http://jint.codeplex.com),它是一个开源的ECMAScript 解释器。
更新
新重写的版本可在 Github 上获取,网址为 https://github.com/sebastienros/jint
You can take a look at Jint (http://jint.codeplex.com) which is an open-source ECMAScript interpreter.
Update
Newly rewritten version available on Github at https://github.com/sebastienros/jint
您应该在 Codeplex 上尝试 Javascript .NET (http://javascriptdotnet.codeplex.com/)。 他们用托管 C++ 包装了 v8,然后您可以将这个库与 .NET 应用程序一起使用,它的工作方式就像一个魅力。 如果你问我的话,开源提供了一些非常好的功能。
干杯。
You should try Javascript .NET (http://javascriptdotnet.codeplex.com/) on Codeplex. They wrapped v8 with managed C++ and then you can use this library with a .NET application and it works like a charm. The open source offers some pretty good features if you ask me.
Cheers.
您可以使用 Jscript.net,它实际上可以处理任意 javascript 代码; 你只需要通过使用
jsc /fast-bar.js
编译来关闭“快速模式”,我还没有测试过这个; 我只是在阅读这篇文章时注意到它并想通了将是另一个合理的解决方案。 MSDN 有此选项的文档以及如果您不使用它会有什么限制< /a>.
You can use Jscript.net and it will actually work with arbitrary javascript code; You just need to turn off "fast mode" by compiling with
jsc /fast- bar.js
I have not tested this; I just noticed it while reading this post and figured it would be another reasonable solution. MSDN Has the docs for this option and what the limitations are if you don't use it.
V8.NET
这可能是我遇到过的最好的一个。
https://v8dotnet.codeplex .com/documentation
另外,它从一开始就考虑到了 Mono 端口。
它使您可以通过托管代码完全控制 V8 引擎的功能。
V8.NET
This one is probably the best one I've come across yet.
https://v8dotnet.codeplex.com/documentation
Plus its been built from the beginning with a Mono port in mind.
It gives you full control over the power of the V8 engine from managed code.
我更喜欢 JINT 而不是
其他的。
JINT 可能很慢,但很容易调试并与您自己的 .NET 类交互。
(每次为 jscript.dll 等设置
[ComVisile]
属性是很困难的)。在线程方面,JINT 和 Jurassic 的工作符合我的预期。 为了使用 JScript 引擎或 Google V8,您必须注意 UI 线程问题。
然而,JINT 在某些方面已经过时了,因为我在编译 JQuery 1.5 或更高版本时遇到了麻烦。
我希望 Jurassic 能够通过创建
'AllowBob'sCLRClass=true'
来消除其限制,以坚持使用自己的类。我必须重写整个课程。 很难...
I prefer JINT rather than the
others.
JINT may be slow, but it is easy to debug and to interact your own .NET classes.
(It is hard to set
[ComVisile]
attributes every time for jscript.dll etc).In terms of threading, JINT and Jurassic work as I expected. In order to work with JScript engine or Google V8, you have to pay attention to UI-threading issue.
However, JINT is out-dated in some aspect, because I have trouble to compile JQuery 1.5 or later.
I hope Jurassic can remove its limit to stick its own class to work with by creating
'AllowBob'sCLRClass=true'
.I have to re-write the entire class. It is hard...