Providing a Scripting Interface for an Application.

N

NeuralJack

Centurion
Joined
Jul 28, 2005
Messages
138
Howdy, I'd really like to provide a robust scripting interface for a VB.Net application of mine. The scripts would be compiled and executed on the fly.

I'd like the user to be able to create functions, classes, etc, if they'd like. But I think that's not the norm for standard scripting interfaces.

I've never used VBScript, JScript, VBScript.Net, or JScript.NET but it appears that if you use VSA to implement them into your program then the user will not be able to create functions, subroutines, classes, etc. It looks like they simply type out a bunch of code that is sort of already in a "Main" subroutine - one that they do not have to declare. Is this correct? That's some pretty limited functionality IMO.

Besides that VSA sounds great with the object-importing etc.

It appears that there is very little info on this stuff. I've heard VBScript.Net refered to at a few sites, but then I can not find any documentation on it. MS doesnt seem to acknowlege it. I can find much more documentation on JSCript.NET however, so I'll probably go with that if i use VSA.

I have found that old-school VB provided much easier ways to implement a VBScript interface, but I'm not interested in old-school VBScript. I'd like an object oriented system so that's another reason to go with JScript.Net. I might be interested in a VBScript.NET if it existed (not sure if it does).

Anyway, then there's this CodeDom I keep hearing about. But i find little to no examples of anyone using it for a scripting interface in an application.

Any Ideas, Suggestions, Comments?
 
I've got another question - this time on plugins. If you provide access to your main form through the plugin interface as a system.windows.forms.form will users be able to use reflection or something to map out all variables, methods etc?

I obfuscate the main program and I realize that people can map out and look at those variables and methods anyway (by looking at the assembly with MSIL disassembler), but i was wondering if if passing the main form to a plugin as a system.windows.forms.form would simplify it for them? I really do not know enough about reflection yet to know either way. Note I am not passing them the main form as the actual real class type - like Form1.

I'd just like an easy way for them to be able to change the color and properties of the main application form and passing it to the plugin is the easiest way.
 
Last edited:
Chances are that simply passing your application's main window to a plugin could give the plug-in a lot more control than you might want. You would be right to be concerned about what could be done with reflection. Anything connected to the form (which very well could be everything) might be accessible by the plugin, as well as properties of the form that you might not want the plugin to be able to access.

My personal recommendation, though I'm no plugin expert, is to provide a wrapper class or interface that allows a less direct method of interacting with the application. Ideally there would be no way to trace a reference from this object back to your application, but you need to balance security and complexity and make considerations such as how many people and what type of users will be using the application, and how important it is to protect your data or program (i.e. is there a legitimate security threat).

There also may be a way to execute the plugin code with restricted security permissions (specifically, deny reflection permissions), but my knowledge in this area is extremely limited and I can't really help you there. It could require that the plugin code is executed in a separate application domain or thread, again requiring you to balance security and complexity.
 
Thanks Marble, I'll just go ahead and keep the plugin interface more restrictive. Instead of passing the whole main form as a system.windows.forms.form I'll just provide functions that will allow the user to change various UI aspects of the main form.
 
Back
Top