views:

1453

answers:

4

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 or try-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.

+8  A: 

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.

Pure.Krome
Excellent, I appreciate the details. If it can handle scripts for YUI Compressor sounds like it should be sufficient for my stuff as well. If you're not wanting to maintain that as your primary objective, it might be easier to get others' help as its own project. I'd be more than happy to contribute any fixes / improvements I make.Thanks!
McKAMEY
I certainly don't want to take ownership of the modified version so i'm happy to have it moved into codeplex, into a seperate project .. assuming the code base i have is .. er .. acceptable :) (I also prefer codeplex over google code :P )
Pure.Krome
It looks like EcmaScript.NET at Google Code ( code.google.com/p/ecmascript-net/ ) had some bug fixes ported in June 2008. It might be worth seeing if your changes would be accepted by the owner.
McKAMEY
Is that a dead project, also?Also, I've released a new version of YUICompressor.NET yesterday :)
Pure.Krome
Not dead but not being actively maintained. Owner says he's open to patches, might want help porting Rhino bug fixes. It would be great if he opens it wider and your fixes could make it into his repos so there was a singular source. Then your repos could focus on YUI Compressor, and others (I'd be willing) could contribute to the maintenance of ECMAScript.NET.
McKAMEY
Kewl :) Well, he's more than welcome to grab the code from the project -> it's all open source, etc :)
Pure.Krome
This works for many situations (esp. YUI Compressor) but I've run into a number of cases where a newer rev of Rhino is needed. Since the EcmaScript.NET codebase has been substantially changed from Rhino (renamed classes, etc.) it will make it nearly impossible to keep it up to date with patches.
McKAMEY
@Pure.Krome -- could you provide a code example of how to use EcmaScript.NET? Please and thanks.
shawndumas
+2  A: 

You can take a look at Jint (http://jint.codeplex.com) which is an open-source ECMAScript interpreter.

Sébastien Ros
Haven't tried it out yet, but jint looks really promising!
Chris Pietschmann
+1  A: 

Everyone seems to be beating their heads against this one:

Other Projects, Mostly Dead:

Crazy Method:

  • Rhino over IKVM (Mentioned in comments, but here's a link to more information about doing it.)
Sean McMillan
+1 for IronJS. I will definitely be keeping an eye on it. It sounds like it is very early on though. Any indication of how well it works?
McKAMEY
+1  A: 

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.

Deacon Frost
Do you (or anyone else) know what sort of caveats there are with this implementation? Is it purely managed? Or does it require a particular processor architecture? I'm curious if it would run on Mono or some alternate CLR.
McKAMEY
Sadly, you won't be able to run it on Mono since Managed C++ doesn't work on Linux so it won't work on Mono. Javascript .NET run on x86 platform since v8 is on x86 and sadly you won't be able to use Javascript .NET in a multi-thread application since v8 doesn't support well the feature.That's about all I know about the project. I used it for my personal application and works well so far.
Deacon Frost