{ End Bracket }
C# to Visual Basic Translation Tool
John Robbins
Code download available at:
EndBracket0408.exe
(206 KB)
Browse the Code Online
Having talked to thousands of developers who use the Microsoft .NET Framework, I've heard one consistent complaint: "I really wish all the samples were written in my programming language." Nothing is more frustrating than having braved the wilds of Internet searches for a snippet of code that does exactly what you want but is written in a language you don't use.
The good news is that you can translate code into your favorite language with a minimum of fuss. I certainly don't want to get involved in any nasty language wars, but for .NET, the two most commonly used languages are Visual Basic .NET and C#, so I'll focus on translating between those.
Since the .NET Framework forms the basis of life, most of the translation is easy (there's only one way to call a method like Debug.Assert). The rest of the translation for code surrounding the Framework method calls involves translating from one set of syntactic sugar to another. Since both Visual Basic .NET and C# show you the squiggly syntax errors, I plop smallish samples into the editor and use these errors to guide me through the translation. The more familiar you are with both languages, the easier this is to do. A good article on translating is "
From VB.NET to C# and Back Again" by Darren Neimke and Scott Mitchell.
At first, I thought I could take some regular expressions I had been using and see if I could tie them together. After a few minutes of sketching, I quickly started sliding into writing a full-blown parsing engine. Since that wasn't what I wanted, I turned to every lazy developer's resource, Google, and looked to see if anyone else had done the work for me. The good news is that I found three great resources.
The first was Kamel Patel's
C# to Visual Basic .NET conversion utility. Kamel has an ASP.NET app that does the conversion, but you can download the code to his parsing engine and run it locally as a Windows Forms app. While there are some bugs in the translation, Kamel's parsing engine is relatively simple to understand and should be easy to fix.
The next site was Alex Lowe's
C# to VB.NET Translator. While Alex does not offer the code, his translation engine does a very nice job. C# #region statements are not translated, but comments are placed in the code indicating where the preprocessor directive was, so you can always quickly go back and poke them in. Alex's page mentions a Web service interface to his translation engine. Unfortunately, it always reports a parsing error a few lines into the code so I could not get it to work, but Alex should get the bugs wrung out by the time you read this.
The amazing Mike Krüger and crew responsible for the excellent open source
#develop IDE have already built in code translation for converting between both languages. If you're looking for a great example of a large .NET-based application to see a robust architecture implementation, take a look at the #develop code. In #develop itself, to convert the current source buffer, simply pick the appropriate conversion from the Tools menu.
At the time I wrote this, #develop was in Beta 1 so the code translation is not feature complete and doesn't handle preprocessor directives and comments. The team is working feverishly on their 1.0 release and is planning to add those two missing pieces shortly.
All of these translation solutions are very nice for converting small source samples, but the real problem is that many times you need to convert a multi-file project. Having needed it myself numerous times, I wrote a tool, CSProjToVBProj, which takes a C# CSPROJ file and converts the whole project, including source, to a VBPROJ file that you can immediately open and compile.
Using CSProjToVBProj is very straightforward, but the implementation is interesting. For reasons beyond me, C# and Visual Basic .NET projects are just different enough to be annoying so there's lots of grunt work involved. For example, in C# all the using statements are in the code, so it's completely obvious what namespaces the developer is expecting. In Visual Basic .NET, most of the Import statements are in the <Imports> element inside the project file itself.
Another more logical hoop I had to jump through is ensuring that I properly update Web files with the explicit codebehind reference to look for the .vb file instead of the .cs file. For version 1.0 of CSProjToVBProj, I am using the #develop translation engine to do the source code translation so you'll need to download and build #develop first. The !READMEFIRST!.TXT file in the project explains the exact steps to build CSProjToVBProj.
If you're looking for a coding challenge, you may want to think about writing a VBProjToCSProj utility so we all can swap back and forth between language projects on a whim.