Code converting VBScript to C#

SyntaxEditor for WPF Forum

Posted 3 years ago by Mick George - Senior Software Engineer, CNC Software, LLC
Version: 19.1.1


I am in the beginning stages of researching a VBScript to C# code convertor.

For context, we developed an editor several years ago that includes full VBScript language support that we extended using our own API's. This allows customers to create add-ins for our software.

We plan to deprecate the VBScript language over the next few releases as we are actively developing a C# scripting language replacement. With that in mind we have a lot of customers that are heavily invested in these VBScripts so we would like to help them with some kind of migration or conversion tool. 

I was curious if anything comes to mind with the syntax editor that we might be able to leverage? Because we implemented VBScript into our editor we have all the language specific information available to use that we can interogate. I would love to hear your ideas, suggestions or recommendations especially from those who may have implemented something similiar.

Thanks for your time.

[Modified 3 years ago]

Comments (2)

Answer - Posted 3 years ago by Actipro Software Support - Cleveland, OH, USA

Hi Mick,

If you've written an LLParser for VBScript and are currently generating an AST, you may have some level of success creating a conversion tool where you parse the AST from VBScript and generate C# code that is largely equivalent. I actually used a similar approach once to do the opposite... take a C-like language and generate VBScript from it. Your rate of success will be directly related to how much detail you currently parse from VBScript.

To take a crude example... consider the following VBScript:

Dim x
x = 1

Your parser might generate an AST with a "VariableDeclarationStatement" and "AssignmentStatement" nodes. Assuming your "VariableDeclarationStatement" also tracks the "Identifier" and your "AssignmentStatement" tracks similar information, you would be able to convert that into C# like:

object x = null;
x = 1;

Since VBScript is typeless, your first challenge may be deciding which default type to use. The object type works, but is really not what you'd want to use for more common types like string, int, and bool. You may even have some luck using "dynamic" in C# instead.

Basic VBScript syntax should be fairly easy to convert, but there are a lot of edge cases to consider.

If your customers don't declare their variables (optional in VBScript when not using "Option Explicit") your AST will not have any declaration statements to convert. If they do have declarations but put them after first use (perfectly valid in VBScript), you'd have to make sure you move the declaration to before first use in C#.

Error handling statements (like "On Error Resume Next" and "On Error GoTo 0") do not have to appear in pairs and thus cannot consistently be converted to C# try/catch blocks.

Now trying thinking about converting all the usage of "Scripting.FileSystemObject" or "Scripting.Dictionary" COM objects to C# equivalents where you aren't just converting syntax, you're completely altering object usage and having to track which variables refer to which object types.

You will also run into ambigous syntax where you cannot easily tell the difference between array access and argument lists like:

Foo = IsThisMethodOrArray(1).Bar

I've worked a lot with VBScript parsing and all the annoying "features" of the language, so I know it's not a straight-forward conversion and many, many compromises will have to be made. But even getting a user half-way through a conversion will save them time.

If you decide to move forward, you can essentially start at the top of your AST and recursively iterate the children where each child AstNode type has logic to output the equivalent C# (perhaps just appending to a StringBuilder as you go). Any AstNode that cannot be converted (or has yet to be supported) could generate placeholder comments of what needs to be done manually.

So "yes", SyntaxEditor can help with the conversion, but you'll still have some pain points. Best of luck if you decide to move forward with this!

Actipro Software Support

Posted 3 years ago by Mick George - Senior Software Engineer, CNC Software, LLC

Thank you for your detailed response and it helps that I was thinking of a similiar approach 👍

The latest build of this product (v24.1.2) was released 3 months ago, which was after the last post in this thread.

Add Comment

Please log in to a validated account to post comments.