Can JScript.NET be used to script a .NET application?

Question

Since MS appears to have killed Managed JavaScript in the latest DLR for both server-side (ASP.NET Futures) and client-side (Silverlight), has anyone successfully used non-obsolete APIs to allow scripting of their application objects with JScript.NET and/or can explain how to do so? A Mono/JScript solution might also be acceptable, if it is stable and meets the requriements below.

We are interested in upgrading off of a script host which uses the Microsoft JScript engine and ActiveScript APIs to something with more performance and easier extensibility. We have over 16,000 server-side scripts weighing in at over 42MB of source, so rewriting into another scripting language is out of the question.

Our specific requirements are:

• Noteably better performance than the Microsoft JScript (ActiveScript) engine
  • Better runtime performance and/or
  • Retention of pre-parsed or compiled scripts (don't reparse on every run)
  • Lower or equal memory consumption
• Full ECMA-262 ECMAScript compatibility
  • a little porting can be tolerated
• Injection of custom objects into the script namespace
  • .NET objects (not a hard requirement)
  • COM objects or COM objects wrapped in .NET
• Instantiation of COM objects from Script
  • à la "new ActiveXObject(progid)"
  • Low priority given the preceeding
• Include files
  • Pre-loading of "helper scripts" into a script execution context
  • An "include" function or statement (easy to create, given the above)
• Support for code at global-scope
  • Execution of code the global scope
  • Retention of values initialized at global scope
  • Extraction of values from the global scope
  • Injection and replacement of values at the global scope
• Calling of script-defined functions
  • with parameters
  • and with access to the previously initialized global scope
• Source-level debugging
• Commercial or Open Source Support
• Non-obsolete APIs

Environ

Will Microsoft still support Managed JScript in Silverlight? – Xenophobia

Nope, gone from Silverlight, too. See this answer: #775839 – Environ

Considering adding ActiveXObject support to Google's V8 engine, having done some work in the past binding C++ to COM via TypeLib information. Will post an answer if this proves viable. – Environ

Answer 1

I answered a similar question here. Have a look at IronJS, an implementation of JavaScript in F# running on the DLR.

Renascence

Answer 2

Sooner or later, I imagine someone will write a DLR Javascript. I know that's not very convenient for you right now, but maybe you could start the project. I suspect it would have a better cost/benefit analysis to using JScript.NET.

Mikesell

Answer 3

If moving away from .NET and Microsoft is ok for you then you should try Mozilla's Rhino. It is an open-source implementation of JavaScript written entirely in Java. Alot of modern server side js libraries target this platform.

Primeval

@Primeval - Have you used Rhino with a Java to COM bridge? Can you comment on performance, ease of integration with C++ code, etc.? – Environ

I'm afraid not, sorry I'm not much help, let me know how you get on though! – Primeval

Answer 4

I have used CSScript.net as it will allow you to run C# as a scripting platform. From the site:

CS-Script combines the power and richness of C# and FCL with the flexibility of a scripting system. CS-Script can be useful for system and network administrators, developers and testers. For any one who needs an automation for solving variety of programming tasks.

CS Script satisfies all the conditions that you laid out. I have used it in production as a substitute for Boo it has performed really well. You can see it in action here.

Gaily

Answer 5

The use of Com interop means you are limited to an MS solution Java and Opensource want as little as possible to do with it.

I dont see any solution that supports all your requirements either you ditch all the COM/.NET stuff and go Java (Rhino) /Linux/Open source or you question the use of Javascript as your server language even in the Linux world we use PHP/Python/Ruby more on the server if we cant run Java. Your not going to see big performance gains with Java script as the language is the main barrier.

I wouldnt count on people writing a new DLR as server Java script is dying fast.

Considering you want performance ,what about F# , Microsoft will keep the Jscript engine supported for at least 5 years giving you time to create new stuff in F# while you slowly migrate the code.

Station

The problem with cross platform is that we need access to over 80 Win32 RPC calls plus a half-dozen DCOM objects, such as WSUS and WMI. I love F#, and use it for prototyping, in-house utilities, and catalog management (at home for my wife's on-line store), but as stated we have over 16,000 scripts written in JS on the server side and cannot afford the cost of conversion to another language. That said, we've looked at jcifs.samba.org, which could prove quite interesting in combination with Rhino. – Environ

Its a case of a rock and hardplace .. The first question is knowing server side Javascript is dying/dead What do you write new code in ? At least if you do new code in f# you do get a smooth migration which can last 5-10 years. You may find 50% of your code is F# in 5 years and it will be fast and run well on 16 cores you have then. Java interop ( ie Rhino) with win32/Dcom /WMI would be problematic but may give you a solution if you resolve those issues. – Station

Answer 6

Have you seen ROScript? http://www.remobjects.com/script.aspx

Supports both PascalScript and ECMAScript (Javascript) syntax

Kami

Answer 7

The Jurrassic-Engine is alive and kicking.

From their codeplex site:

• Supports all ECMAScript 3 and ECMAScript 5 functionality, including ES5 strict mode
• Well tested - passes over five thousand unit tests (with over thirty thousand asserts)
• Simple yet powerful API
• Compiles JavaScript into .NET bytecode (CIL); not an interpreter
• Deployed as a single .NET assembly (no native code)
• Basic support for integrated debugging within Visual Studio
• Uses light-weight code generation, so generated code is fully garbage collected
• Tested on .NET 3.5, .NET 4 and Silverlight

Akira