I'm not all that against VB.NET, but I'll be honest -- I normally cringe when going to a client site that uses it exclusively. The reasons are many and varied, but most of the time my fears are groundless... But one thing that gives me night terrors is seeing VB.NET projects with Option Strict not turned on.
Back in the days of VB6, those people wishing to write second-rate and error-prone code had the nifty switch called “Option Explicit” - To simplify it, we'll say it's a compiler switch that said “Error the compile if variables aren't explicitly declared before use”. It stopped you from saying Dim Abcde as Integer on one line, and DoSomething(Abce) on another. I can't tell you the number of times I'd get handed code, turn Option Explicit on in a file and immediately have the build break. Yikes! Never once was there an acceptable reason to do this. (One person did start in on performance nit-picks - don't let me get started).
The best part was that the great (no sarcasm, VB6 was, and a great tool for many purposes) people who brought us VB6 turned the option off by default for what I imagine was compatibility reasons. So most people never turned it on, and many of them turned out poor-quality code (I don't know what's cause and what's effect here, did great developers turn it on, or did turning it on make developers great? My bet is more the latter than the former, but I'm sure it helped to catch errors at compile-time)
Now we have Option Strict ( I don't need to explain all of what it does, this is the web - I link ) Which restricts implicit type conversions. It also verifies that functions have return types and all paths return a value -- all things that that the C# compiler always verifies. It's a performance helper(by elimitating hidden type conversions), catches lots of possible errors, and is generally a must... but again, it's off by default (AAARGH!). I'm sure the reasons for that are many and good, but.... AAARGH.
Why is it a must? Well, I've been fixing lots of code, and here's something I must have fixed four times, just this week - a bug that can be very subtle and hard to track down without Option Strict.
Public Function Something(Arg1 as AnEnumType) As SomeObject
Select Case Arg1
Case AnEnumType.A
Return New SomeObject(1)
Case AnEnumType.B
Return New SomeObject(2)
Case AnEnumType.B
Return New SomeObject(3)
End Select
End Function
Why is this bad? Well, what if I add a new enum to AnEnumType, say AnEnumTypeD... what gets returned? Nothing, that's what. And when you just know that a code path has to return an object this can be fun to track down. There are lots of other cases where this happens, involving catch blocks that don't rethrow but cause the return to be skipped, If's with no Else's, and so on, but they're all bad.
So please, code with Option Strict on -- if you start with it off, it can be hell to go “strict-ify” your code later. Us poor slobs who have to add features later will sure appreciate it.