I should just ignore that last line there as at this point it's got to be flamebait...but just in case you're really still that ignorant of what vb.net is at this point....
C# and VB.NET are one and the same at this point, really just wrappers for the CLR that have syntactic differences, but share all the features of the other. Sure, at any given point one or the other is slightly ahead in terms of feature set, but that flips back and forth constantly.
What's really a problem with your statement however is the implication that vb is anything even remotely similar to vb.net. This is dangerously naive at best. Place where I work has a lot of old school vb6 devs. Myself and a few other new devs are rebuilding the core system in .Net. Management really wants this done in vb.net so that the other devs will be able to easily migrate into the new environment. I'm still fighting this, it's the WORST mistake they could make. See, at least if they start off in the new system using c#, then they will know for sure that things are different, and adjust accordingly. But if it looks like vb, and they can turn off all those flags like option strict, then it will behave like vb too! Oh joy!
You see, there really are two vb.net languages, the proper one, and the one that imports the VisualBasic namespace and turns off all the compile time type checking measures meant to hand-hold those few remaining vb6 devs on their way into the land of .net. Unfortunate as this does lead to mistaken ideas about what vb.net is.
Personally, I actually prefer both for certain things. C# for plumbing and back end work, intricate lambdas, things like that...syntax is just cleaner for this kind of stuff. Vb.Net for front end work, it's just quicker, and in some cases somewhat clearer about what exactly you're doing with events etc. Besides, the not quite as good devs will tend to stop at the c# line and come ask for help instead of diving in to muck stuff up.