GBVB - Converting VB.NET code to C#

• Download source files - 59 Kb
• Download executable - 17 Kb

GBVB - Converting VB.NET code to C#

“GBVB (Goodbye VB) is an amazing tool that flawlessly converts any portion of VB.NET code to C# code in a fraction of seconds.” I would love to be able to say this. If you are looking for such a tool, forget about it. You will not be able to find it, and I will explain why later in this article.

Why convert?

Isn’t .NET all about language interoperability? Why would someone ever need to convert VB.NET code to C#? Well, even though the languages are fully interoperable, there are some good reasons for this conversion:

1. The VB.NET code is still not strongly type-checked. It still makes some type conversions that may be dangerous. Try this code, with Option Strict On, for an example (both are true):

           Dim x As String
           If x Is Nothing Then
               Console.WriteLine("X is Nothing")
           End If
           If x = "" Then
               Console.WriteLine("X is an empty string")
           End If
   

2. Most C# programmers find VB.NET syntax ugly and cumbersome. I know this is a matter of personal taste, but it is a good reason for code migration. If you do not feel comfortable using a language, it may be better learn to either love it, or get rid of it.
3. C# features several compile-time code checking, besides strong typing. Access uninitialized variable, assign values to a variable and never user it, or declare a variable and do not use it, create unreachable code, and you will get an error or a warning from the compiler. VB.NET silently compiles this kind of code.
4. Since it is easier writing a C# parser (I will write about this later in this article), there are and there will always be more for C# code analyzing and rewriting, while VB.NET will receive much less attention in this area.
5. Because of some VB.NET ambiguities, sometimes VB.NET code can be slower than the C# equivalent.

Not Possible to Write a Perfect VB.NET to C# Converter

It is not possible to write such a perfect tool because VB.NET syntax allows a programmer to write ambiguous code. VB.NET syntax ambiguities follow in two categories:

• A parser needs type information for disambiguation, e.g., when you see the code ambiguous(3), you need type information to know if this is a function call or an array access. When translating to C#, you’ll need to either use ambiguous(3) or ambiguous[3]. Actually, this does not make it impossible to write such a tool, but it makes it harder.
• Some code using the Object data type can only be disambiguated at runtime, e.g., ambiguous(3) will only be resolved on runtime. Actually, it can change from one call to other. This kind of code is impossible to translate. One could use some heuristics to determine the runtime data type at parsing time, but it would be hard and yet not 100% effective.

Approaches for Code Conversion

• Anakrino! Well, this is a reasonable idea, until you really try it. Just a tip: do you know the VB compiler does not put your comments on the final assembly? There are funnier things, too, but I will let you discover them by yourself.
• Regular expressions. Come on, you can come up with something better than this. Again, a tip: try to write a recursive regular expression.
• Write a parser. That is what I did. It is not so much work as it appears, if you keep yourself writing a simplified LL(1) grammar and if you use a nice tool, such as COCO/R for C#.
• Do everything by hand. I have done that, and I can tell you: GBVB will prevent RSI like no other tool.

Goals and Restrictions

With the previous knowledge in mind, I decided to make a tool that converts some “well-behaved” VB.NET code to C#. Let us define some goals for GBVB, sorted by priority:

1. Garbage in, Garbage out: if you give the converter some garbage code, you will have more garbage.
2. This is a typing-saving tool: GBVB will do repeatable most hard and repeatable work, but you still will need to do “brains” part. Some code will not be translated and sometimes you will get an error on the output: if needed, comment the affected code. The converted code does not even need to compile, but it should be faithful to the original VB.NET code.
3. It should be very useful for converting my own code: if it is useful for you too, hey, it is your lucky day! Nah, I am just joking: actually, GBVB could translate nearly 90% of my code, so you will be very unlucky if GBVB do not for you.
4. This should be an easy-to-code tool. Fast to code, too. As such, I hope you do not find that my coding style produces excessive commenting on the source code at a point that makes it hard to read.
5. This is not a pretty printer (it is more like an ugly printer): it does generate indented code, but it does not generate highly organized code. By goal #2, it is up to you to organize it as you wish. Pressing Ctrl-K F on the generated code sometimes helps.
6. I explicitly decided not to use heuristics, because of goal #2 and #4.
7. No VB runtime functions will be converted to the .NET Framework “equivalent” ones, e.g., Mid(x) will not be converted to x.Substring. Although easy, as I show you later, this would introduce several bugs and would need revision anyway, without the compiler errors to help you. Don’t you believe me? Run this code, just for fun:

           Dim x As String
           If x Is Nothing Then
               Console.WriteLine("X is Nothing")
           End If
           If x = "" Then
               Console.WriteLine("X is an empty string")
           End If
           If Mid(x, 1, 1) = "" Then
               Console.WriteLine("Mid X is an empty string")
           End If
           If Len(x) = 0 Then
               Console.WriteLine("Len(X) == 0")
           End If
           Console.WriteLine(x.Substring(0, 1))
   

8. On Error Goto / On Error Resume Next will only be part of GBVB over my dead body. See Goal #1.
9. The Goto Statement: See Goal #8.
10. The REM is an abomination used only by some distorted minds. There is the one char line commenting, did you know?
11. Most array code will have trouble while being translated.
12. Some VB.NET syntax keywords and features are not supported, like Handles, inline array declarations. Goals #2, #3, #4, and pure laziness.
13. I made it using Visual Studio .NET 2003. I do not even have Visual Studio .NET 2002 on my machine anymore.

Using the tool

Look at the screen shot: if you cannot figure out by yourself how to run and use this tool, you should not be programming. Try something easier, there may be some exciting jobs for you on the food market. Alternatively, keep with VB.

Converting from VB6 code

A direct conversion is sometimes possible, but the VB Upgrade Wizard will do a much better job. Therefore, I do strongly recommend you to upgrade the code to VB.NET, run it, test it, fix it, and only then convert it to C# code.

Some advices before migrating

• Only migrate solid, working code. Create a rigorous unit testing set (you already have this, right?) and only then migrate your code. This way, you can be sure your code runs the way it is supposed to run.
• You will need to change some things before migrating, because some features are not support by either C# or GBVB. While still working on the VB.NET code, I recommend you to change the following things:
  • Get rid of your optional parameters.
  • Use Option Strict On and Option Compare Binary.
  • Classic On Error error handling is not supported in C#. Change this code to exception handling.
  • Modules are not supported, but Friend classes that have only Shared methods can easily substitute them. Bear in mind that often code on Modules have global variables and is not thread safe, especially if migrated from VB6 (VB6 code ran in STA, so it was not susceptible to this kind of problem), so you can see this as a good opportunity to break it in smaller classes.
  • Change Select Case with conditions and exception filters, if you use them.
  • Finally, remove all the VB runtime functions and use only the .NET framework equivalent ones. Do you remember the VB.NET weirdness I mentioned? Well, having a sound unit testing set will ease things to you.
  • If GBVB has trouble to migrate some statement, comment it, and migrate it manually. You will notice the trouble because GBVB will often stop the code migration on a specific statement.
  • After migrating, do some code cleaning. Normally, C# will give you hundreds of healthy warnings about your “perfect” VB.NET.

Improvements

• It could be an add-in for VS.NET. For now, I recommend you to add it to the Tools menu.
• GBVB is only able to migrate “full” code files. Code snippets do not migrate nicely.
• Do not complain of my commenting style, I know that so many comments like I did can make the code hard to read! Besides this, there is a mix of Portuguese and English words on the identifiers, which makes looking at the sources a rather “globalized” experience. But, if you are experienced with COCO/R, the code is plain obvious and easy to follow.
• GBVB do not support the “one line” If Then, nor multiple statements on the same line.
• Remove the LL(1) warnings, and the “Not Expression” annoying messages.
• Create an option for the brace position. It is easy to change the Util.OpenBlock and the Util.CloseBlock methods for this.
• It is very easy to add some automatic translation of VB.NET runtime functions if you like to live in danger. In a future version, this will be implemented as optional features. On the VBNET.ATG file, change the Expression compiler production and add specific translation for your code. Like the sample below, where I convert a Len(expression) to Expression.Length (if you didn’t use it before, see the power of COCO/R!):

      Expression<out string exp> =
      (
          “Len”
          ParentExp<out exp>    (.  exp += “.Length”; .) 
          |
          "True"                (.  exp = "true"; .)
          |
                  

Acknowledgments

This tool was only possible because of the C# version of COCO/R, by Hanspeter Moessenboeck.

I used the version modified by Pat Terry, available here.

Actually, I slightly changed the version, because all the parsers I write need to be thread safe and deal with accented chars. This specific parser needed also a delegate on the commenting parser, because COCO/R by default ignores comments, which is a good thing, but not in this case. Therefore, everything that is working ok has to be credited to Pat & Hanspeter, and every bug may have been introduced by me.

I did not put my COCO/R changed sources on the ZIP files because I cannot assure you if my modified version is fully compatible with the original, only that it suits my needs. If you are interested on the sources, mail me and I will send you.

License

You can use all the code wrote by me in this article (everything but COCO/R, which is subject to its own licensing) and distribute it freely, as soon as you keep the Copyright notice. If you create some derived work, put a link back to this article, citing me as the author of the original work, as I have did on the Acknowledgments section. You cannot sell nor license this code without my written authorization, but you can make sell or license the code you converted using it.

The Standard Disclaimer

As I said before, I tested this on my machine and it works fine. Use it at your own risk: if you use it, you can lose data, profit, have hardware problems, cause radioactive contamination and start a nuclear world war. However, for me, it works fine and never had such a problem.