added javascript wrapper objects
Should never rely on webBrowser; it's the backing field for the WebBrowser property (which should be used instead of going straight to the backing field...).
One file per class, bitte... :smiley:
Removed the <value> stuff. I don't really think we need it, it just clutters the class and doesn't really add that much value.
Minor tweaks, and removed @JanEggers assumption that we might have stuff here which is not present on the managed side of the world. I'll leave that out for now, you can implement it later if you like Jan.
Let's go with the name "Javascript" everywhere, instead of JavaScript. The latter is arguably more "correct", but the former is also quite widespread and you could very well claim that "Javascript" is a such a common name that it can be normalized to follow normal "name rules", i.e. capitalize first letter only...
Split out the member descriptions into two child classes: JavascriptMethodDescription and JavascriptPropertyDescription. (We don't have to support direct fields at this point, I think; properties should be very much enough for most needs.)
Whitespace fix.
Don't want to have this here. @JanEggers, I presume that the idea from your end was to support more complex object graphs? (i.e. My.Fancy.Property being exposed to Javascript...)
I'll leave that out for now, but feel free to fix/experiment with that at some point.
Again, one class per file is better.
Trivial whitespace fix.
Fixed the creation of the Javascript proxy client to happen at the right time, i.e. when a new browser is created. That should be massively more efficient in terms of speed than connecting to the service on every JS call. :)
Trivial whitespace fixup.
ObjectBase is now DisposableResource, which better explains what it pertains to.
Jan - I think it actually is better after all to keep everything related to the Subprocess in its own repo (i.e. the subprocess repo). That way, we can separate the concerns more elegantly (IMHO).
Let's extract this out since I realized we are violating the important DRY principle.
Let's make this more strict, so that it actually works and isn't too "relaxed", in the strictly-typed world of C#/.NET...
Use the CreateChannelFactory-based approach here also.
Added an important TODO comment.
Fixed naming of the SubprocessProxySupport class. Let's go with "Subprocess" for now generally.