> If you were to look at the compilers themselves or try to write a perfect automatic conversion tool you'll quickly see that far from identical.

There's so much truth in this.

Telerik has a online conversion tool[1] you can us, which can batch convert entire code-bases. But a 1-to-1 straight conversion cannot be done with 100% accuracy, and the tool will tell you everywhere it struggles to figure out the right C# equivalent for the corresponding VB.Net code.

I've used this tool in the past to "eliminate" the last remnants of VB-code in our organization. And when you do a job like that, on that scale, you definitely notice the differences.

A quick list of things you can expect to cause troubles (from memory and may not be 100% accurate):

- The difference in VB global/C# static semantics.

- The (default & overuse) of late-binding in a typical VB codebase. (While that wasn't an option for me back then, this can now be overcome by using "dynamic" everywhere, but that's hardly idiomatic C#)

- VB Modules can cause issues.

- For a full conversion, you'll typically have to rewrite all code using the functions and operands only found in the Microsoft.VisualBasic namespace. Not all these have straight up C#/BCL replacements.

Etc etc.

For being superficially so similar, a conversion job is actually much more work than you would typically imagine.

[1] http://converter.telerik.com/