I recently chose to write my libraries in C# even though I could have done it in VB because C# supports API description via ///. You can then pick up description through intellisense. I think this will be rectified in the next release though.

Additionally, I find that my C# ADO.NET code runs between 2-6% faster. This has to do with VB compiler generating more code than it needs -- have a look at the IL code -- same IL, just more of it from VB compiler.

I love VB when I work with Office automation. I hate to have to pass missing values to Office API when working with C#. When I don't know which version of Office my client has, VB is great for that too because I can use late binding -- tough to do with C#. You can also provide arguments explicitly with VB, saving lots of typing for long-a## argument list. Another thing -- optional parameters are great with VB.

only fast developing, running is too slow

I was joking about Europa, which is FoxPro for .NET. VB and C# are both adequate.

Randy,

I have to disagree. I've been writing both VB and C# codes for close to 3 years now. True the IL code is the target for both compilers, but the actual IL code instructions are different. VB puts out MORE IL codes because VB isn't as type strict as C# so more stuff has to be put out to ensure runtime safety. You can find a study of this here:
www.nycdotnetdev.com/EventDetail.aspx

From a utilitarian standpoint, I write VB codes when I automate Excel because VB supports optional params and Office object models are awfully long. Also VB supports late binding to COM objects so I don't have to worry (much of the time) which version of Excel users have. This is a difficult proposition in C#. Otherwise, I like C# because it has fewer bugs, e.g., auto gen assembly version, and more features that I use on the server side, e.g., lock, using, ternary operator, etc.

Regards,
Paul