Option Strict
The most important thing to do in VB, in my (absolutely not humble) opinion is to use Option Strict On at all times (except, on a per-file basis, when non-strict typing makes sense, e.g. because you use PIA to interoperate with MS Office) and to enable it in the VS options.
Option Strict On, together with Option Explicit On, gives roughly the same behaviour as C#. Switched off, it removes a lot of type checks at compile-time and allows spurious, unnecessary and hard-to-debug implicit conversions between completely unrelated types.
Option Strict Off makes sense when working with COM API. Option Explicit Off never makes sense. It's stupid (and mainly there for VB6 compatibility).
Comparison: = versus Is
Another thing to look out for: equality vs. reference testing. In C#, you use == for both. In VB, you've got distinct operators:
Dim StringA = "Hello"
Dim StringB = Console.ReadLine()
Dim EqualContent = StringA = StringB
Dim EqualRefs = StringA Is StringB
Now depending on the user input, EqualContent may be True; EqualRefs will always be False. Beware that Is here is semantically equivalent to the following C# code (which nobody ever writes, usually):
var equalRefs = object.ReferenceEquals(stringA, stringB);
I actually think this is an advantage in VB over C#, but one rarely needed. The opposite of Is is IsNot. Another thing to pay attention to here is that the string comparison via the = operator actually calls a VB runtime method: Microsoft.VisualBasic.CompilerServices.Operators.CompareString.
This takes into account several other settings, especially the Option Compare setting which may be Binary (default, behaviour like in C#) or Text (case-insensitive comparison).
CType versus DirectCast and TryCast
The VB runtime is called in some other cases as well, one of them notably CType which is a general-purpose conversion operator in VB. I tend to avoid using the operator and I strongly advise anyone doing the same, in favour of other, more explicit conversions. The reasons for this is that CType tries several semantically very different conversions, when applied. This makes it hard to track what exactly is going on in the code, potentially introducing typing errors.
For one thing, CType allows parsing of strings for numbers. This is a concept better expressed through the NumberType.Parse operation, as in C#.
Instead of CType, I advise usage of DirectCast which is the equivalent of the C# cast, or TryCast which is the same as C#'s as conversion.
Another gotcha. When checking whether an object x has a certain type T, the following syntax has to be used:
If TypeOf x Is T Then …
Notice that this doesn't invoke the normal reference comparison operator Is. Rather, it uses an own operator construct TypeOf … Is …. You cannot write TypeOf … IsNot …, though. This is probably a bug in the specs.
Misc. …
There are a lot more differences, some useful (e.g. the differences in the Select Case statement) and some less (e.g. the Like operator for basic wildcard matching … just use regular expressions instead).
Some other questions relating to this: