The most exciting thing about this world is its ever changing quality.

Monday, November 17, 2008

Script engine in .Net

Embedded script engine in applications which require significant level of customisation is a very attractive idea. More than that, the script based component actually makes the component level deployment possible, a different implementation to plug-in structure. One thing to look out for is surely performance.

  1. CS-Script is claimed to support on .NET1.1/2.0/3.0/3.5 versions of CLR implementation with limited support on Mono. It effectively creates the support for CLR code compilation. You have accesses to all the libraries supplied from .Net. With the use of configuration file for scripts, you could really extend your application functionalities. In addition, you can take advantage of other CLR compilers (by instantiating System.CodeDom.Compiler.ICodeCompiler interface) and Config console. Referring to namespace would be able to access your own object model. One good thing is that with CS-Script, you can compile any scripts into standalone executable.
  2. Prior to .Net 3.5, namespace Microsoft.Vsa offers the built-in scripting capability. Vsa really is a .Net version of VBA. You create your own instance of engines from Microsoft.Vsa.IVsaSite interface, from which you can implement your engine to accommodate VB script, Java script and C# script engine. An easy tutorial can be found at here. You could expose your object model within your application to be reused from scripts later on as well.
  3. Good old days - Microsoft Script Control used in managed project. Again, you can expose your own class model via this. You would need to instantiate an instance from MSScriptControl.ScriptControlClass and then select the script engine for either VBScript of JavaScript (of course MS version of JS). This article has introduce an interesting way of scripting asynchronous call.
  4. There are a few other script engines projects available as well. Google will take you there I am sure. I will not go on here.
Be aware the difference with Windows Script Interface. WSH enables Windows OS to run scripts in a way extending batch file. By default Windows will interpret JS and VBS files, with WSF you should be able to have a sense of language independent OS scripting. Although WSI has been deprecated since .Net 3.5. You could even create script COM objects using Window Script Component. However, Windows Script allows you to script capability at OS level. If you imagine Windows as AN application (well, not the best one shall we say), and Windows Script provides a way to Script this application.

No comments: