D Melodic Minor Accidental

A conglomeration of random thoughts on C#, .NET, OOP, and working at Microsoft

This Blog

Syndication

Search

Other Sites

Personal Site

Comparing C# and VB.NET

A reader wrote me just now:

Hi,

I just came across your blog and seeing that you're mentioning random thoughs on .NET, I was hoping you'd be able to answer this question: Is there any real difference to coding in VB or in C# when it comes to the .NET framework? If there are differences, do they still exist when I narrow the topic down to .NET web applications?

Thanks,
Max

When it comes down to it, in my opinion, there aren't many significant language differences between VB.NET and C#. Most of the constructs in those languages are achievable from the other language, which is why you'll often see samples online in both languages. I think VB.NET includes more implicit conversion operators, as well as a bunch of other constructs if you disable option-strict compiling (such as late-binding). C#, as a language, will generally be more explicit than VB.

With VS 2005 (C# 2.0), C# includes anonymous methods, which are not a VB construct - VB users can workaround it by declaring new types/methods as necessary (which is what the C# compiler does under the hood). C# 2.0 also supports new iterator methods (using the yield keyword), which I think is unsupported by VB.

VB includes a ton of "built-in" functions, which usually delegate to other .NET framework library functions that are accessible by C#. Because of that, VB programs load several .NET framework DLL's that are not always needed in all programs, but are required for supporting VB built-in functions. In C#, a lot of what the language does to supplement the .NET Framework isn't providing specific built-in functions per se, but more language features, that affect the way your code is compiled (instead of introducing other dependencies).

In regards to ASP.NET and web applications, I don't think that the above discussion applies any differently - the ASP.NET integration should be nearly identical for both languages. Any preference towards choosing VB over C# or vice versa will probably be off of developer's taste.

I'm sure other folks out there will point out other important differences between C# and VB, but these are the ones that come to mind.

Published Monday, June 20, 2005 2:05 PM by TheoY

Filed under: Random .NET Platform

Comments

# re: Comparing C# and VB.NET @ Monday, June 20, 2005 3:14 PM

Thanks for the explanation. Personally, I prefer the C coding syntax over VB's, but as you pointed out, it's the developer's (or in this case the boss's) choice :)

Max

# re: Comparing C# and VB.NET @ Monday, June 20, 2005 3:19 PM

The answer I would be interested in would be is there IL that can be generated by C# code that cannot be generated from VB code (regardless of how much longer the syntax needs to be), and the reverse.

Protections would be one. It is possible as well (but not advisable) to create a class in C# that has both:
private void DoIt() // and
private void doIT()

which is not possible in VB.net, also not CLS.
Things like that. How about Interoping or Unsafe code?

theCoach

# re: Comparing C# and VB.NET @ Thursday, June 23, 2005 11:22 AM

Regarding syntax, I'd have to admit that I'm more acclimated to C-family languages (C/C++/C#/Java).

Regarding different IL operations - I'm not an expert at this, but a couple of things come to mind, but most of these require advanced knowledge of the CLR:

(1) VB allows users to make a non-virtual call to a virtual method. I've seldom wanted to do this, except for where I think the API was missing something. For example, when an object overrides Object.GetHashCode(), there usually is no way for other code to access what the original Object.GetHashCode() *would* have returned (which is usually based off of a hash for some uniqueness of each object instance). In VB.NET (and C++ for .NET) you can *non-virtually* call GetHashCode() and actually call into the implementation defined by the System.Object class.

This breaks a lot of assumptions of programmers who are assuming that overriding a base virtual method will obscure the ability to directly invoke the base implementation. I'd take a pretty confident guess too, that most VB.NET programmers either don't use this, or aren't aware when they are using it.

(2) I think "yield" iterators, a C# 2.0 feature, employs a special construct of try/fault under the hood, if you're using "yield" in the scope of a try/finally block.

(3) Like you said, C# supports unsafe code, and VB doesn't. Unsafe code has a whole family of IL operations...

(4) VB allows exception filters (similar to C++/SEH filters) so that you can run an expression while you're deciding to handle the exception. This is useful if you'd like multiple exception blocks to execute the same catch logic, but it makes it harder to discern whether a catch block may or may not be evaluated.

TheoY