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
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.
Public Class World
SayHelloWorld() As String
Return "Hello, World! From VB.NET Component!"
public class World
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.
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
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.
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
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!