This project is read-only.

Customize Wrapper / implement parts of the wrapper in pure c#

Mar 3, 2012 at 7:33 AM
Edited Mar 3, 2012 at 9:12 AM

after played arrount and got the newest(!) V8-Engine with noesis.javascript wrapper in .NET 4.0 x64 mode to work, i played a little bit around. I tried to write an complete other wrapper for the V8-Engine, but my c++ skills are absolutly too low. So, here i have some hints for you:

My goal is, to make the getter/setter calls generic, so it would be possible to override them. Than it would be possible to decide for each object, if it should be converted to and js-array (copy) or it would be accessed by indexer-calls(no copy, and slower) and so on. So each object "could" be an custom object with custom getter and setters or/and custom indexed getters/setters.

Maybe i oversee some things, but this could be the prototype(so you see, what i mean):

With an custom implementation, it would be possible:

- the implementation on c++/cli-side is so small as possible, only the really needed logic is there.
- custom getters/setter with or without index.
- custom delegates
- get/set extra-values not existing in .net objects (like = value, HtmlElement has no property foo, but this is possible in js)
- control the Handle-Caching via hashtable(Key-->NET Object, Value-->JsObjectHandle), so every context can (or cannot, depend on custom implementation) have its own set of Handles even on global shared .NET objects. For example, multiple contexts(=multiple script users) have shared .NET object, they can get/set custom properties, but they do not affect other contexts(users). And they do not stay in memory -> when the context is destroyed, the "attached"(via hashtable) handles/wrappers are deleted, too.

You say, this project is dead. I do not think this. I can help to write the complete c# side(my skills in .NET are very high) and make it open source here for this project. My onliest(big) problem is the c++/cli side. You said, we should use jurassic. It's slow(for an high performance app) and global shared objects are not possible, and all have to be inherit from an special class(for serialization). This is not acceptable.

And there's spidermonkeydotnet, of course. This is like my example above:
i need to figure out, if the shared .NET object strategy works there. And it has no 64 bit support yet.

Greetings from Germany,

Mar 4, 2012 at 7:44 AM

Hi Sebastian

I too am in the same boat. I would love to use the this engine (as it appears 5x faster than the IE9 engine on the few test I have done) but I can't even get the thing to compile, never mind tweak the C++ code which is not my thing.

On the other hand, I have managed to implement a lot of what you suggest with wrappers for the IE9 engine. IE9 Javascript object are IExpando COM objects so I have a JSObjectWrapper which wraps objects created in the js context. I also have support for js arrays (which are really Lists since their length can be changed).

An example C# property would look like this:

public string ID { get { return (string) GetProperty(CSLNames.ID); } set { SetProperty(CSLNames.ID, value);} }

where the SetProperty would create the property on the Js/IExpando object as required.

I don't have support for objects shared between contexts but I haven't found a need for that - I just create a new context. But it would be nice to be able to create a new context from the same scripts without having to reparse them. Also support for heirachical contexts would be useful - it would support your need for global variables (one top level context and then many child contexts) and mine with an empty top level context and many independent child contexts. 

I also found that I needed support for lazy-instantiated child variables (arrays and/or child js objects). Without that, JSON produces lots of empty items which I have to avoid.

What I disliked about the current Run() method is that it tries to decode whatever the current object is rather than just return its handle. That just crashes for me since my result object is basically a graph and it throws an out of stack space almost immediately. The system seems based on creating copies of object for use in the other environment whereas my primary use us to have objects in the js context but accessible from C#.

I need to be able to 

1) Have a void Load() method to add individual scripts into a context.

2) Have an Execute(..) method to call js methods and return either primitive values or object handles

3) Be able to Execute methods on wrapped JS objects.


All of this seems perfectly simple from the C# side of things but the C++ side is beyond me.

I'm willing to work with Sebastian and anyone else on speccing a solution but I don't think I would be much help on the C++ side.


Mar 5, 2012 at 12:15 AM

Hey Simon,

i tried now , but it has no x64 binaries, too. But i was able to compile the original sources of the spider-monkey engine(pure c++, from the official mozilla sources) in x64 mode, and recompile than the c++/cli (mixed mode) dll. It seems to work. And from the beginning on with less problems.

The spidermonkeydotnet project seems not to be more "active", but the wrapper seems to be more complete. constructors, delegates, field-members(in classes) are no problem, error handler and lots of stuff is offered. and a "dynamicproperty" feature is offered, too.

And in comparison of the native (pure c++) api of v8 and spidermonkey, it seems spidermonkey have the better one, and better documentation. ( ). And as you know spidermonkey (please keep in mind, tracemonkey=spidermonkey) is in the newest firefox browser. And it's not extremly slower than V8 .... ;)