> 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 mu

> 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/ http://converter.telerik.com/