Converting C# knowledge to VB.NET any potential problems?

Question

I have a team with people that are quite comfortable in C# but we got a requirement to write a project in VB.net. How hard would it be to think in C# and on the fly convert to VB? Is that doable?

Could you list the issues that we can come across?

I heard that VB.net doesn't have closures. Is that still true for .net 3.5?

Answer 1

If you are approaching VB.Net with the mindset of C# it's best to set the following options in the project

• Option Strict On
• Option Explicit On
• Option Infer On

This essentially removes the late binding semantics of VB.Net and forces it to be a strictly typed language. This will make it closer to C# semantic wise (still not exact by any means).

VB.Net has Lambda Expression (and hence Closure) support starting with the Visual Studio 2008 / .Net Framework 3.5 release. Not expression and not Statement. Statement lambdas are not supported until VS2010 / .Net Framework 4.0. Although you can use the 4.0 compiler to downtarget 2.0 frameworks.

Answer 2

As C# and VB.NET uses the same framework and compile to very similar IL code, you have a lot for free. Writing Basic syntax instead is not that hard.

The C# syntax is more aimed at showing what's going on, while the VB syntax often hides away some details, so a C# programmer is already familiar with some concepts that may not at all obvious to a VB programmer. In some ways learning C# is a better way to learn how VB works than to learn VB itself...

I frequently answer VB.NET questions in different forums mostly based on my C# knowledge, and I still haven't written anything more than short test programs in VB.NET myself.

There are of course some quirks to look out for in VB. Like the / operator for example that always converts both operands to double, or the = operand that uses VB specific comparison code rather than the comparison specified for the equality operator in the .NET classes.