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

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.

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.

One area that VB.NET tends to try and cover up is working with events; others have briefly touched on some of the differences, but here's a little more on them:

VB.NET provides a WithEvents keyword for fields that raise events. If the field is declared WithEvents then you can add a Handles field.Event to the end of a method whose signature is compatible with the event; that method will automatically be a delegate of the event without needing to manually AddHandler and RemoveHandler (+= and -=).

Private WithEvents SomeField
Public Sub SomeField_SomeEvent(sender as Object, e as EventArgs) Handles SomeField.SomeEvent
    Console.Writeline("SomeEvent occured")
End Sub

Event declarations and raising events are simplified a bit. VB.NET doesn't require that you check if an event is null prior to notifying listeners:

Public event SomeEvent as EventHandler(of SomeEventArg)
Public Sub SomeMethod()
    RaiseEvent SomeEvent(Me, new EventArgs)
End Sub

One "hidden" feature of events in VB.NET is accessing the underlying MulticastDelegate, to do something like GetInvocationList() Note: the event is named SomeEvent and the code to access the multicastdelegate calls an invisible field named SomeEventEvent:

Public event SomeEvent as EventHandler(of SomeEventArg)
Public Sub SomeMethod()
    // Note that SomeEvent's MulticastDelegate is accessed by appending
    // another "Event" to the end, this sample is redundant but accurate.
    // If the event was named ListChanged then it would be ListChangedEvent
    dim invocationList = SomeEventEvent.GetInvocationList()
End Sub