The Problem Solver

Visual Basic or C#, after the battle

1. Office/VSTO development.
   The Office object model was created with optional parameters, a feature of VBA, in mind and makes heavy use of it. As Visual Basic supports this it has an advantage over C#, unless of course you like typing Type.Missing :-)
2. COM interop with older applications.
   And in this case I am specifically referring to COM interop without a complete type library, something common in VB6 or Visual FoxPro. This is where Option Explicit Off is a great helper and time saver.

1. Very large projects.
   In these cases the complete background compilation of the VB IDE and related updating of the Error List window might become a drag. That said I have not worked on a Visual Studio 2005 project where I experienced this.
2. Unmanaged code.
   While there is no speed difference between C# and VB when it comes down to managed code C# leaves the option of unmanaged code open. Unmanaged code makes direct memory manipulation possible, something we showed in a graphics demo where the unmanaged C# version was more than 20 times faster than either the managed C# or VB code.

• Well keep the product team focus in mind. The C# team focuses in correctness while the VB team is more focused on RAD. So if you want to develop applications faster you should consider VB and if you want more predictable and verifiable results take C# instead. This difference exists today but will increase in the future so choose wisely.
• If you are a manager you might want to consider the average developers background. The C# developer is more likely to have an academic background, something that translates into more theoretical knowledge, higher pay and lower availability.
• Your development focus. C# translates into framework/library building and VB into the glue that puts everything together. Of course you can use either language for either purpose but if you make a choice depending on your activities this is it :-)
• If you want to work with multiple languages that’s ok, although I would recommend not. Just make sure you stick to C# for the library/framework stuff and VB for the application glue. Doing it that way should work fine but doing it the other way round is a big nono in my book.
• Personal preference. And that is the big one and the reason most choices are made. Just be fair and admit its only personal preference and don’t hide behind fake technical arguments :-)