This project has moved and is read-only. For the latest updates, please go here.

Is .Net seamless integration a future possibility?

Dec 15, 2010 at 8:00 PM
Edited Dec 15, 2010 at 8:01 PM

Hi Paul,

I see in your docs how to access a .Net class from Jurassic but I'm wondering if you're planning on taking the more seamless approach.   That is, use the import keyword to pull in .Net libraries ( and make the whole access thing IJW (It Just Works...much like Microsoft's JScript.Net does it).

Or, if Jurassic were to go to that level of development, it may as well go the DLR route and then access everything .Net  DLR/CLS compliant Tough projects.   But from looking at your code, I think you can do anything in programming you put your mind to.


Dec 16, 2010 at 4:10 AM

I had no plans to improve .NET class access - but now that you mention it, it is a bit unwieldy.  Regarding an import keyword, I would rather not alter ECMAScript (I am trying to be as compliant with ECMAScript 5 as possible).  However, I'm not averse to adding a .NET API to easily add classes to the global namespace (without requiring that they inherit from ObjectInstance or have the required attributes).  I have added that and DLR support to my list of "things to do".

What are the Tough projects?  You mean IronRuby, IronPython, etc?

Thanks for the compliment - but that OS I tried to write proves you wrong ;-)

- Paul

Mar 13, 2011 at 2:00 PM

With DLR support I suppose seamless integration will be achieved, right?
I'm really looking forward for the DLR support, so that I can set any .NET object in the ScriptScope, and the JavaScript source will be able to invoke methods of that object.
For now I will derive my .NET objects from ObjectInstance, but it would be nice to be able to write an API that can be used by JavaScript, Python or Ruby all at once.

Mar 14, 2011 at 12:59 AM

Just yesterday I checked in a change that enables seamless .NET interop.  For example, you can do this:

scriptEngine.SetGlobalValue("Math", typeof(System.Math));
scriptEngine.Evaluate("Math.Atan2(1, 2)");

This means you can access existing .NET classes from javascript without any attributes and without having to derive from ObjectInstance.  However, this does not use the DLR and so does not interop with Python or Ruby, sorry!

This feature is not quite ready but I am hoping to do a v2.2 release with this feature in the next week or so.

- Paul

Mar 14, 2011 at 1:37 AM

Hi Paul,

How cool are you - that change makes it great for me to use this engine, because now I don't have to create (not so) funny classes that describe properties: instead I can go ahead and write normal .NET classes and use them from your script engine!
Right now it's perfectly fine if it's not using the DLR, but it is important to know that it will do so some time in the future. It would be so great to have JavaScript lined up next to IronPython and IronRuby.

Thanks a lot for the great work you did so far, and I hope you will continue investing in this work. Once I have implemented this engine in my game, let me know how to buy you a beer.

Mar 14, 2011 at 7:41 AM

Thanks for the kind words but I can't promise anything re: DLR.  I went down that route at the very start of the project and it was a disaster - I had to do a big rewrite to get rid of it.

I definately plan to continue investing effort in this project, but it will be at a reduced rate since I now have a full-time job.  And you don't have to buy me a beer - just knowing that people are using this thing is reward enough :-)

Jul 15, 2011 at 9:55 PM

To be honest, I think I would be disappointed to see Jurassic be in the DLR.  Jurassic was incredibly seamless and easy to use; the DLR is hard to understand and write code around, IMO.

The problem I see with DLR support, I think, is two-fold:

  • From the developer-user side, it makes the default tasks of integrating the script engine into your project harder.  Instead of tightly coupling to the language,you have to work around all of the abstractions the DLR provides.  That's nice, but it's so generic that it's sometimes difficult to understand.
  • From the implementation side, you then need to implement all of the binding rules to make the DLR interpret JavaScript code and non-JS code calling JavaScript objects still behavior JavaScript-ish.

I like the DLR in principle, but it's, in my mind, still very much a 1.0 inclusion in the .NET base class library.  The fact that they've abandoned VBScript and JScript in favor of Python and Ruby is disappointing, particularly because JavaScript is such a predominant language on the web.

Oct 18, 2011 at 6:39 PM


I'm guessing the seamless .NET interop has not yet made it into the release build, since we're still at v2.1 ?  Can you comment on the status of this feature? e.g. If I were to build the dll from source, does the seamless integration basically work?


Oct 18, 2011 at 9:08 PM

Yup, seamless .NET interop basically works, there's just a few corner cases I'm still working on (notably, being able to instantiate .NET primitives like System.Int32 in JavaScript).  Check out the unit tests in Unit Tests > Core > ScriptEngineTests.cs for details on what you can do.