C# or VB.NET: World War III

Introduction

I know many .NET developers have this question in their mind. Which language do I use to develop .NET applications? C# or VB.NET? Well, In this article I'm going to go under the hood and show you want really happens to the applications developed in C# and VB.NET.

Language is realign 

For some developers the programming language that they are using is like realign for them. If you talk anything bad about the language then you can get in to good hot heated argument with the developer. You can even see this in your day-to-day life at work, user groups and bulletin boards, some times articles on this topic. 

Before .NET framework was introduced, every language was using its compiler to produce native code (processor specific). Some of the compilers where optimized for a specific operating system of processor. In this scenario each language capabilities and compiler capabilities where really mattered. For example, when we develop a COM component in VB 6, it had the Apartment Model Threading (STA) and STA had its won drawbacks. When you want a lighting fast COM component then, people where relaying on ATL and VC++ to do it. And more over, when we develop COM components in VC++ we had more control over the component and we can remove the unwanted COM glue methods from our COM components. But this is not in the case of VB 6. VB 6 helped us to create COM components at the speed of light and it took care of all the COM glue methods for us.

The .NET and JIT Compilers 

Well, it is an old story after .NET Framework has been introduced.  In .NET framework when we compile a Portable executable (PE) or a component, the code is compiled in to Managed Code/Intermediate Language (MSIL or IL). This MSIL uses CPU-independent set of instructions. 

The .NET Runtime ships Just-In-Time (JIT or JITter) compiler, which will convert the MSIL code in to the native code (CPU Specific code). So whatever code we write will be complied in to MSIL format and after that our code is history. 

The .NET runtime/Common Language Runtime (CLR) ships three different classes of JITters. The Main JIT compiler converts the MSIL code it to native code with out any optimizations. The JIT compiler takes the MSIL code and optimizes it. So this compiler requires lot of resources like, time to compile, larger memory footprint, etc. The PreJIT is based on the Main JIT and it works like the traditional compilers rather than Just-In-Time compilers. This compiler is used at the time of installation.

A Simple Test 

Well we know what will happen to our code, when it is passed on to VB.NET compiler or C# compiler. So all it matters is MSIL format that what we've to worry about. Because once our code has been converted in to MSIL format, from MSIL format all the code that we write will be converted to native code in the same way never the less if it is a VB.NET source or C# source. Microsoft climes that if we choose VB.NET or C# the code should be same. To test it I'm going to write two .NET components (DLL's) in VB.NET and C# which does the same things. Here how the code looks. 

VB.NET code: 
 

Imports System
Namespace Hello
Public Class World
Public Function SayHelloWorld() As String
Return "Hello, World! From VB.NET Component!"
End Function
End Class
End Namespace

C# Code:

using System;
namespace Hello
{
public class World
{
public string SayHelloWorld()
{
return "Hello, World! From C# Component!";
}
}
}

In both VB.NET and C# code, we've a namespace called "Hello" and it includes a public class called "World". The "World" class exposes a public method called "SayHelloWorld". Simple is in it? Let's compile the above code.

VBC /t:library /out:VBComp.dll /r:System.dll VBComp.Vb

CSC /t:library /out:CSharpComp.dll /r:System.dll CSharpComp.cs

We've asked the VB.NET and C# compilers to produce a DLL file (library) by including the System.DLL file for the reference.

IL Disassembler 

The .NET framework ships a tool called IL Disassembler, which can open a managed component or a PE (Portable Executable) and show the MSIL Code and Meta data associated with it. 

Let's fire the IL Disassembler (Go to Start > Programs > Microsoft .NET Framework SDK > Tools > IL Disassembler) and open the both VB.NET and C# version of the DLL. The following figures show the IL code generated by the VB.NET and C# compilers. 

VB.NET IL Code 

 

 
 

C# IL Code 

 

If you can look at the code closely both look the same way for the method "SayHelloWorld". But VB code one more overhead called "_VBProject". I was thinking of doing a performance test against the both components. But ASP.NET and .NET Framework is still and it's first beta and this version is kind of proof of concept and just for learning. So, it didn't make any sense for me doing that. More over Beta 1 license agreement prevents doing such tests.

Summary 

As for as I'm concern the language of choice is up to you. If you've a VB background and you feel pretty good about VB then dive in to VB.NET. If you come from a C or C++ or Java or JavaScript background and you feel pretty good about C like syntax then dive in to C#. All it maters is the language that you are familiar with and how productive you are in that language.

Until next time, Happy Programming!