c# is faster than vb.net
C# can access unmanaged code in the background
c# has more functionality

vb.net is partially oops,were c# is full oops ...
multiple multilevel is not possible in vb.net...in c# its 
available.

Multiple Inheritance is not possible in VB.NET, you have to 
use Interface to achieve this.

In C# multiple inheritance is available.

As every code is compiled to byte code in MSIL, it does not 
make a difference is execution speed.

OOPs is added to VB.NET, whereas C# has it as part of it.

VB.NET is easy to learn, C# is easy to write !! choice is 
yours!

VB.NET & C# both have same execution speed no difference in 
terms of speed.

But there are some other differrence between them:-

1- C# uses function pointers, VB.Net does not.
2- we can do operator overloading in C#, but not in VB.Net.
3- VB.Net uses WITH KEYWORD, C# does not have WITH Keyword
(Example:- WITH datagrid
 .datasource=ds          
.databind()
END WITH)
4- C# is case senstive language, but VB.Net is not.
5- C# is fully object oriented language it implements all 
the concepts of OOPs. But VB.net is not fully OO language 
because some of the OOPs features like operator loading it 
does not have.

Correcting some minor misinformation in prior answers:

1. As has already been stated, all .NET languages compile to MSIL, so given the same basic code structure, there is no difference in execution speed. Of course, either language may have features that encourage more or less efficient coding structures in certain circumstances, but the compiler optimizers usually catch many of these and optimize them accordingly.

2. VB.NET can indeed do operator overloading with the Operator statement (this may have been added to newer versions such as VS2005 since the previous answers were posted).

3. C++.NET can do true multiple inheritance (MI), but C# cannot. Indeed, C++ mainly does so with MFC, a pre-.NET unmanaged-code technology. The .NET Framework is designed not to need MI. In all .NET languages including VB.NET, the concept of Interfaces allows a limited form of an MI-like concept. A single Class can Implement multiple Interfaces, but Derive from only one parent Class. It can even do both in the same Class — again, regardless of language.

4. In more modern versions of both languages (C# 2.0 & 3.0, VB.NET 9+), LINQ and many supporting technologies to enable and empower LINQ were added.  These are very powerful in their own right as well as enabling the power of LINQ, and C# does indeed currently have an advantage here: lambdas are implemented much better in C# than in VB.NET (they can be multiline in C#, one expression only in VB.NET, and C# allows void-function [C-type language equivalent of Subs, namely, doesn’t return a value] lambdas while the current VB.NET 9 still doesn’t allow lambda Subs, only single-expression single-return-value Functions), C# allows Automatic Properties (a very powerful code saver, but useless for technlogies such as WPF that extend the concept of properties [e.g. WPF Dependency Properties]) while VB.NET doesn’t yet (but will in .VB.NET 10 / VS2010 / NET Framework 4.0). Code Snippets mitigate the Automatic Properties thing anyway. Both have Extension Methods, Anonymous Types, etc.

Some items not directly related to OOPS but often missed in discussions like this:

1. C# (like other C-derived languages) has post/pre inc/decrementer operators (++, --), plus operate-and-assign operators (e.g. +=), bitwise shifts (<<, >>), short-circuiting logical operators, the ternary operator (?:), etc. While not widely known among those not familiar with it, VB.NET in its latest versions does currently have all of those except the post/pre inc/decrementers. Much of their functionality can be done with += or -= ("myCounter += 1" isn't that much harder to type nor convoluted than "myCounter++", but of course the latter does have the powerful advantage of being usable in expressions).

2. The VB.NET version of the ternary operator (introduced in VB.NET 8 or 9, IIRC) looks like a function, but is not: If(booleanExpression, trueValue, falseValue) -- this is not to be confused with the actual IIf(,,) function available all along which looks similar but is not short-circuited and is a function, not an operator.

3. VB.NET now provides nullable value types, simply by putting a question mark after the Type ("Dim discount As Decimal?"). Nullables have a ".HasValue" Boolean property, and a read-only ".Value" property. A two-operand overload of the If() function-like operator allows for providing a default value in case of a Null (Nothing in VB.NET), similar to the ISNULL function in T-SQL or a two-operand COALESCE function in ANSI standard SQL:

salePrice -= If(discount, 0@)  ' If the discount amount is Nothing (null), treat it as 0, avoiding a Null Value runtime error.

Longer equivalent using ternary variant of If() operator:

salePrice -= If(discount.HasValue, discount.Value, 0@)

4. Dates and times are standard VB.NET types that have existed since way back when in VB. C# still doesn’t have them, and must resort to .NET classes. This means that you can have date and datetime literals in VB (simply delimited with “#”), while you have to parse a string or provide int parameters to initialize a Date or DateTime even to a known constant value in C#. While the C# optimizer may be smart enough to handle such circumstances, if it didn’t, this is one obvious example of when VB.NET would produce faster code.

Const santaDue As Date = #12/24/2009 12:59:59 PM#  ' compiles right to an actual datetime literal constant! No run-time hit!

vs.

DateTime santaDue = DateTime.Parse("12/24/2009 12:59:59 PM");  // string literal has to be parsed and converted — inefficient!

DateTime santaDue = new DateTime(12, 24, 2009, 23, 59, 59);  // somewhat more efficient (no string literal to parse, but int literals have to be stuffed into date/time parts at run time), yet still not a pre-compiled literal constant. Not as intuitive to read, either.

I’d be interested to know if the C# optimizer can recognize such initializations using string or integer constants and optimize them.