JScript.NET能用于编写.NET应用程序的脚本吗？

Question

由于 MS 在最新的 DLR 中似乎已经杀死了服务器端（ASP.NET Futures）和客户端（Silverlight）的 Managed JavaScript， 有人成功地使用非过时的 API 来允许使用 JScript.NET 脚本化他们的应用程序对象，并且可以解释如何做到这一点吗？如果 Mono/JScript 解决方案稳定并满足以下要求，则也可以接受。

我们有兴趣升级脚本主机，它使用 Microsoft JScript 引擎和 ActiveScript API，以获得更好的性能和更容易的可扩展性。我们有超过 16,000 个服务器端脚本，总大小超过 42MB 的源代码，因此重新编写成其他脚本语言是不可能的。

我们的具体要求是：

• 比Microsoft JScript（ActiveScript）引擎具有显着更好的性能
  • 更好的运行时性能和/或
  • 保留预解析或编译的脚本（不在每次运行时重新解析）
  • 更低或相等的内存消耗
• 完全符合ECMA-262 ECMAScript标准
  • 可以容忍一些移植
• 将自定义对象注入到脚本命名空间中
  • .NET对象（不是硬性要求）
  • COM对象或包装在.NET中的COM对象
• 从脚本实例化COM对象
  • 类似于“new ActiveXObject(progid)”
  • 优先级较低，考虑到前面的内容
• 包含文件
  • 将“帮助程序脚本”预加载到脚本执行上下文中
  • 一个“include”函数或语句（鉴于以上内容，易于创建）
• 支持全局范围内的代码
  • 执行全局范围内的代码
  • 保留在全局范围内初始化的值
  • 从全局范围提取值
  • 注入和替换全局范围内的值
• 调用脚本定义的函数
  • 带参数
  • 并且可以访问先前初始化的全局范围
• 源级别调试
• 商业或开源支持
• 不过时的API

- James Hugard

---

微软是否仍会支持Silverlight中的Managed JScript？ - Nosredna

不，它也已经从Silverlight中消失了。请参阅此答案：https://dev59.com/EkfRa4cB1Zd3GeqP702g#886173 - James Hugard

考虑将ActiveXObject支持添加到Google的V8引擎中，之前已经通过TypeLib信息绑定C++到COM进行了一些工作。如果这种方法可行，将会发布一个答案。 - James Hugard

Answer 1

我在这里回答了一个类似的问题。请看一下IronJS，它是在DLR上运行的F#中JavaScript的实现。

- user29439

Answer 2

我想迟早会有人编写DLR JavaScript。我知道现在对你来说可能不太方便，但也许你可以开始这个项目。我猜测使用JScript.NET比较好的成本效益分析。

- Julian Birch

Answer 3

我使用CSScript.net，因为它可以让你将C#作为脚本平台运行。以下是该网站的介绍：

CS-Script结合了C#和FCL的强大和丰富性，以及脚本系统的灵活性。CS-Script对于系统和网络管理员、开发人员和测试人员非常有用。对于任何需要自动化解决各种编程任务的人来说都很有用。

CS Script满足您提出的所有条件。我已经在生产中使用它替代Boo，表现非常出色。您可以在这里看到它的实际应用。

- David Robbins

Answer 4

如果您可以放弃使用.NET和Microsoft，那么您应该尝试Mozilla的Rhino。它是一个完全用Java编写的JavaScript开源实现。许多现代服务器端js库都针对这个平台。

- thatismatt

---

@thatismatt - 你有使用过Java到COM桥接器的Rhino吗？你能评论一下性能、与C++代码集成的易用性等方面吗？ - James Hugard

很抱歉，我恐怕帮不上什么忙，但请告诉我你的进展如何！ - thatismatt

Answer 5

你看过ROScript吗？ http://www.remobjects.com/script.aspx

支持PascalScript和ECMAScript（Javascript）语法

- George Birbilis

Answer 6

Jurrassic-Engine 活著並且非常強大。

從他們的 CodePlex 網站上可以看到：

• 支援所有 ECMAScript 3 和 ECMAScript 5 功能，包括 ES5 嚴格模式
• 經過良好測試 - 通過了超過五千個單元測試（超過三萬個斷言）
• 簡單而強大的 API
• 將 JavaScript 編譯成 .NET 字節碼（CIL）；不是解釋器
• 部署為單一的 .NET 程序集（沒有本機代碼）
• 基本支持在 Visual Studio 中進行集成調試
• 使用輕量級代碼生成，因此生成的代碼完全由垃圾回收
• 在 .NET 3.5、.NET 4 和 Silverlight 上進行了測試

- Sebastian

Answer 7

使用 Com interop 意味着您受限于 MS 解决方案，而 Java 和 Opensource 希望尽可能少地涉及此类解决方案。

我没有看到任何支持所有要求的解决方案，您可以放弃所有 COM/.NET 的东西并转向 Java（Rhino）/Linux/Open source，或者您可以质疑在 Linux 世界中使用 Javascript 作为您的服务器语言，如果我们无法运行 Java，我们在服务器上更多使用 PHP/Python/Ruby。使用 Java script 不会带来大量性能提升，因为语言是主要障碍。

我不会指望有人编写一个新的 DLR，因为服务器端的 Java script 正在快速消亡。

考虑到您需要性能，那么 F# 如何？Microsoft 将在至少 5 年内保持对 Jscript 引擎的支持，这给您时间在 F# 中创建新的内容，同时缓慢地迁移代码。

- ben

---

跨平台的问题在于我们需要访问80多个Win32 RPC调用以及半打DCOM对象，例如WSUS和WMI。我喜欢F#，并将其用于原型设计、内部实用程序和目录管理（在家里为我妻子的在线商店），但正如所述，我们在服务器端编写了超过16,000个JS脚本，无法承担转换到另一种语言的成本。话虽如此，我们已经看过http://jcifs.samba.org，结合Rhino可能会非常有趣。 - James Hugard

这是一个进退两难的情况...第一个问题是，如果服务器端JavaScript正在消亡/已经死亡，那么你会用什么编写新代码？至少，如果你使用F#编写新代码，你可以获得平稳的迁移，可以持续5-10年。在5年内，你可能会发现你的50%代码是F#，并且它将在你拥有的16个核心上快速运行。Java互操作性（即Rhino）与win32/Dcom/WMI可能会有问题，但如果解决了这些问题，可能会给你提供一个解决方案。 - ben