A long (long) time ago, if you wanted your users to be able to enhance your product by add coding logic, you pretty much had two choices:
- Dig into Lex and Yacc or….
- Roll your own parser and scripting execution engine.
Then, around the time VB 6 was released, Microsoft introduced VBA. It worked, but it was expensive and a god awful complicated mess to integrate with your app, so outside of Microsoft Office (which even as of Office 2010, still supports it!), very few applications actually made use of it.
Around the same time, the Microsoft Scripting Control was released. This was an ActiveX control you could use from any COM compatible language to embed VBScript. Now, of course, this is VBScript, not a “real” language like C or even VB. But, it was free, easy to obtain, and very easy to use.
As the years have rolled by, .NET has steadily grown in capability and while the Windows Scripting Host exe is still shipped with Windows, the old VBScript and JScript scripting has largely been supplanted by either:
- ASP and more recently ASP.NET
- Dynamically compiled .NET code
- and likely lots more options I’m not familiar with
Now, all these options are good, and each definitely has it’s place, but, for many purposes, good ol’ VBscript still fits the bit quite nicely.
But can you use it from .NET? And if so, how?
The Tempest in the Teapot
Before I continue, I should point out that any time you start talking about allowing users to add their own code into your application, you’re opening up a huge can of worms that you’ll need to deal with. Things like properly catching exceptions from badly written user code (yeah, that never happens), adding watchdog timers to deal with hung and infinitely looping user code, security concerns, and the like all will have to factor into the decision. You have been warned <g>.
So Simple It Hurts
I had a plugin project recently where I wanted to give the user the ability to write some very simple logic to expand the functionality of the application.
Of course, I wanted to build a full plugin API, but I also wanted to provide a lighter-weight option for those users that didn’t want to dive head-first into a full on .NET project. VBScript seemed like the obvious choice.
A few Google searches later and most everything I found was talking about how to dynamically compile .NET code, which is cool indeed, but not what I was really after. Other articles and posts insisted that users should convert their VBScript code to .NET (ok, yeah, but that’s not really the point now is it?).
Then I did a Google Desktop search of my own system and turned up some VB6 code I’d written ages ago to experiment with the Microsoft Scripting Control.
Now, I know that .NET languages support accessing ActiveX Controls and COM objects in general, but this was pretty old stuff. Would it actually still work?
I cobbled up a dirt simple VB.net project:
Public Sub Main() Dim Script = New MSScriptControl.ScriptControl Script.Language = "VBScript" Script.AddCode("sub Main" & vbCrLf & "MsgBox ""This is a Test"" " & vbCrLf & "End Sub") Script.Run("Main") End Sub
Be sure to add a reference in the VB.net project to the COM object “Microsoft Scripting Control”.
Run it, and lo and behold, I get the “This is a Test” message box, straight from VBScript!
Obviously, there’s lots more to making use of the Scripting Control than just this, but, clearly, VBScript is still very much a choice for adding limited programmable logic to your application.