There is a white paper on this topic, differences between VB.NET and C#
http://support.microsoft.com/?kbid=308470
VB.NET has background compilation, which is a huge plus. It automatically
detects errors as you edit your source code. In C# errors are detected when
you build your project.
It's also a bit simpler to do late binding. For example, if you want to
support multiple versions of office without knowing in advance what version
it is, you need to use late binding.
In VB.NET you would do
option strict off
....
Dim excelApp as object = CreateObject("Excel.Application")
excelApp.Visible = False
Dim excelWorkbooks as object = excelApp.WorkBooks
The equivalent in C# is
Type excelType = Type.GetTypeFromProgID("Excel.Application");
object excelApp = Activator.CreateInstance(excelType);
object[] params = new Object[1];
params[0] = true;
excelApp.GetType.InvokeMember("Visible", BindingFlags.SetProperty, null,
excelApp, params);
object excelWorkbooks = excelApp.GetType.InvokeMember("Workbooks",
BindingFlags.GetProperty, null, excelWorkbooks, null);
It's a lot more cumbersome in C#.
With that said, I much prefer C# because there are more options for
Refactoring.
The .NET framework is centered around object oriented development. In my
opinion OO and Refactoring go hand in hand. The SmallTalk and Java tools
community have had automated refactorings for a long time. However it seems
Microsoft OO tools have been extremely late in this. C# in VS.NET 2005 will
have automated refactorings built in, but VB.NET will not. IntelliJ has
ReSharper, which is an excellent refactoring add-in for C#. It also does
background compilation a la VB.NET.
There are no viable VB.NET refactoring tools out there.
Automated refactoring may not be important for a lot of people, but it is
important for me. Writing good maintainable code that adheres to OO
principles is the reason why anyone should use an OO language.
