Posted on 2004-10-22
Last Modified: 2013-11-25
I need detailed information on which language to choose to start with .NET . Some say VB.NET is always better, some say industry is seeking for developers, and C# got much more popular. I need statistics and number if possible, and/or real life examples from your experiences.
Thanks in advance.
Question by:phpisthefuture
    LVL 20

    Assisted Solution

    In the job market C# is definately popular , at least on dice I saw that. Microsoft has developed C# becuase they want to make life simple to  Java guys, but if you already have VB background it is easier to go to than C#. I am from VB background, but I use C# and frankly it took me little extra time to learn ans still learning. would have been my ideal choice, but I wanted to learn C#
    LVL 28

    Accepted Solution

    C#  has pointer operations
    VB is case insensitive. In C# MyA and myA are differnt variables
    VB supportd late binding and optional parameters, C# does not
    C# doesn't support optional paramters
    VB supports automatic variable conversion between types (you can assign Long to Integer without conversion)
    VB has richer IntelliSense and better automatic formatting
    VB better supports compilation while you type.If you misspelled keyword and move to another line
        the error will appear in the Task List.

    - C# is as equally suited to application program development as VB.NET
    - Productivity between the two languages is comparable
    - Execution speed of programs written in both languages is comparable
    - VB offers improved as-you-type checking, but inferior compile-time
    checking (relying on runtime checks instead)
    - Both languages have advanced Intellisense features (resolving case
    issues in C#) with the VB Intellisense being slightly more advanced
    for Booleans and Enums
    - Comparable statements can be up to 266% shorter in C# - with or
    without Intellisense

    Ease of use
    - C# has half the number of reserved words to learn
    - Both languages have identical class, method, and function names (the
    - To be used properly, both languages require knowledge of object
    orientation, event driven programming, and exception handling
    - Both languages are not immediately accessible to non-programmers

    - C# is fully object orientated, ie 'int.Parse(x)' whereas VB uses
    some legacy non-OO function calls
    - VB supports as-you-run modifications
    - C# supports XML commenting
    - C# is supported by other platforms (Borland C#Builder, and 'Mono' on

    - Knowledge of VB is useful for programming Office and VBScript
    - Knowledge of C# is useful for programming Javascript, Jscript, PHP,
    Perl, Java, C and C++ (currently the dominant language for native-code
    development on both Windows and non-windows platforms)

    from Marco Bellinaso article
    What C# has that Vb does not
    1.Unsafe code:
    with C# you can write blocks of unsafe code, that is,
    code that can use pointers and directly access memory, use low level
    system calls and do the sort of things that are not verified by the CLR.
     Use of this feature should be avoided to limit the possibilities of
    runtime errors, but it may turn out to be an important feature when
    writing code for algorithms that must have good performance, or need to
    interface with the operating system (of course, operating system
    portability would be lost by doing so).

    2. Operator overloading:
    C# allows the developer to define a custom
    implementation for many mathematical, unary, binary and comparison
    operators that a class may support, such as +, -, *, /, true, false, ==,
     !=, >>, <<, !, ~. For example, say that you have a class Matrix: you
    can redefine the meaning of the + operator for this class, so that if
    you have three instances of Matrix - m1, m2 and m3 - you can do m3 = m1
    + m2;. While this is certainly a very cool feature, you must be aware
    that if you later use the Matrix class from a VB.NET client, you won't
    be able to use the overloaded + operator to sum two matrixes, since the
    operator overloading feature is not part of the CLS. If you're 100% sure
     that all your code will be in C#, good, you can safely overload the
    operators and assign them the meaning you want. Otherwise, you should
    provide instance or static methods such as Add, Subtract etc., so that
    all the possible operations are accessible to VB.NET too.

    3.  XML documentation: (Whidbey will have it)
    in C# code comments can be added in XML-like
    format--with a /// prefix instead of the usual single-line // comment
    prefix--within tags such as <summary>, <para>, <returns> and so on. At
    compile time you can specify to extract all the XML comments and save
    them to an XML file, so that it will be easy to write a XSL
    transformation file to create HTML documentation. If you program with
    Visual Studio .NET, under the Tools menu you find a Build Comment Web
    Pages item, that generates the help files without requiring you to
    manually write a XSL file and leave the IDE. Once the developer gets
    used to writing their comments between these tags, they will soon
    realize that they already have good documentation of their classes,
    separated from the source code and thus easier to read and consult. This
     powerful and helpful feature unfortunately is not present in VB.NET.
    Hopefully it will be added in a future release, but I'm pretty sure
    someone will soon provide an add-in to support this feature in any
    language, if it doesn't already exist.

    4.  Unsigned integers:
    the uint, ulong and ushort data types. Unsigned
    integers may be useful in some situations, when you want to handle just
    positive values, but I wouldn't say it's a vital feature. Also, as for
    the operator overloading, unsigned integers are not part of the CLS, so
    if you define a method that requires an argument of this type, you won't
     be able to call it from VB.NET. You can safely use them within the
    method's body though, without compromising the compatibility with other
    languages, the important thing is just that they are not exposes in
    public methods' signatures.

    5.  The using statement:
    defines a block of validity for an object
    variable. As soon as the execution goes outside this block the object is
     destroyed and disposed. This is good when the developer uses limited
    resources, and wants to free them as soon as possible.

    6  The checked and unchecked statements:
    specify whether the expressions
     and constants within the defined blocks raise compile-time errors or
    runtime exceptions in case of an overflow.

    7  The ? : conditional operator:
    this is a ternary operator, used in the
     form of op1 ? op2 : op3, that evaluates and returns the result of the
    second operand if the evaluation of the first operand returned true,
    while evaluates and returns the result of the third operand otherwise.
    This is really useful when you want to return a value or set a variable
    with a different value according to some condition. In VB6 you have the
    IIf operator that does the same--in VB.NET the IIf operator is still
    available, but only in the Visual Basic compatibility assembly, so it's
    not really part of the language itself or the framework library, and its
     use should be avoided. Personally, this is something I'd be very glad
    to have built-in in the VB.NET language, I miss it when I program with

    8.  The ++ and -- operators:
    these operators increment or decrement a
    variable by one. For example, instead of writing x += 1 (the += is
    supported by both C# and VB.NET) you can write x++. While they may be a
    little bit clearer to use the more verbose syntax in single statements,
    they are particularly handy to use in for blocks to increment/decrement
    the index variable.

    9  add/remove accessors and the EventHandlerList class:  
    just like the
    get/set accessors for properties, C# also has the add/remove accessors
    for events. As you can easily guess, they are used to add fine-grained
    control to the addition/removal of event listeners. You can use them in
    conjunction with the EventHandlerList class, that represents a list of
    key/value pairs, where the key is an object that identifies an event,
    and the value is a delegate. This class in often used in components and
    controls that expose a lot of events, because they avoid having an event
     member for each class event, thus making a more efficient use of memory.
     There is no VB.NET counterpart to the add/remove accessors, so the
    EventHandlerList class is of little use in VB.NET. This is a significant
     defect if you are a class/component/controls developer.

    10.  Non-serializable events:
    when you serialize an object (an instance of
     a class marked by the Serializable attribute) you'll also serialize all
     the objects that are references. If your class exposes events, this is
    a problem, because its listener objects are actually referenced by the
    object (since the events are implemented through delegates), and thus
    the serialization mechanist tries to serialize them as well! If the
    listener is a serializable class you'll "simply" end up serializing more
     objects than you really want, but if the listener is a Windows Form you'll
     get no less than a runtime exception, because forms aren't serializable.
     C# has a very elegant way to solve the problem: you just need to apply
    a [field: NonSerialized()] attribute to the event declaration, and the
    event will not be serialized. Unfortunately, VB.NET does not support the
     "field" target for the NonSerialized attribute. Check out the article
    at for more
     information and a couple of proposed workarounds for VB.NET.
    11.  C# has been submitted to the ECMA committee to become a standard.
    This also means that
    other vendors will be able to develop and sell their own compilers and
    IDEs for C#, while
    this won't be possible with VB.NET, as it is Microsoft-proprietary. If
    the .NET Framework
    will ever be successfully ported to other operating systems

    What VB.NET Does Have That C# Doesn't

    1.  As in VB6, with VB.NET you can still use the CreateObject function to create an object
    instance of a class defined in a COM component with late binding. In C#
    instead, you necessarily need to create a .NET wrapper assembly and reference it, or
    use reflection to access the wrapper assembly if you want some sort of late binding. It is
     of course much easier in VB.NET, even though you should avoid the CreateObject function
     if you want to write code can than be easily translated to other .NET-compliant languages.
    2.  If in C# you want to handle events raised by some objects, you necessarily need to use
    delegates to programmatically and explicitly associate a custom method
    to the class instance, and say that that's the event handler procedure for some
    method. This technique is possible in VB.NET too, but VB.NET also allows you to declare object
    variables with the WithEvents keyword, that hides the use of delegation to associate a
    custom method to the object instance, and instead allows to write a method and directly
    associate it to the proper object instance by means of the Handles keyword, that specify the
     event that the procedure handles. This really makes it faster to write code to handle
    events, especially if you use Visual Studio .NET because it lets you select the event name
    from a drop-down list, and autogenerates the required code.
    3.  VB.NET supports optional arguments, with a default value if they are
    not passed to the method. While this may be useful at times, this is not a CLS-compliant
    feature, and C# clients won't be able to take advantage of the default value for the
    optional arguments and will always need to pass all the arguments. If you think there is
    the possibility that your classes will be called by C# clients the best practice is writing
    overloaded versions of the same methods, with a different number of parameters, to simulate
    optional parameters. Here's an example, instead of writing:

    Public Sub DoSomething(Optional ByVal arg As Integer = -1)
          ' ...
    End Sub

    You can write these two overloads for the DoSomething method:

    [Overloads] Public Sub DoSomething(ByVal arg As Integer)
          ' ...
    End Sub

    [Overloads] Public Sub DoSomething()
        ' call the version that takes one argument, and pass in the default
    End Sub

    Overloads is between square brackets in the code above because it's
    optional, but if you use it in one declaration, then you must use it in the other overloaded
    versions as well. This way, C# clients will also be able to call the overloaded method
    with a variable number of arguments.

    However, there is one case in which this feature is very, very handy--when
     you use COM Interop to access COM components that expose a lot of methods with
    optional parameters.
     If you do a lot of add-in programming, this point might be enough to make you choose VB.NET!
     In addition, note that you can't write VS.NET macros in C# as you do with VB.NET, and
     this makes it much more difficult to run and test snippets of code--you have to
    compile the full add-in and debug it. Alternately, if you want to test a piece of VB.NET code,
    you can just extract and save it as a macro and run it. Try to compile, register and
    run everything dozens of times just to find and fix one bug in a routine, and you'll
    really appreciate what VB.NET offers in the add-ins development field!

    4. VB.NET's With...End With block executes a set of statements on the
    defined object. Practically, if you're settings a lot of properties or calling a lot of
    methods of the same object, you declare a With block for that object, and within the
    block you access its members without writing the object name, but only with a dot (.) prefix.
     This is a nice feature that can make your code lines a bit shorter and faster to write.
     You'll also have is a slight performance benefit, because when you use the With syntax
    you have a temporary reference to the bottom-level object which can speed things up.
    5.  VB.NET still supports modules (defined within a ModuleEnd Module
    block, and not identified by a .bas file as in all the previous releases of VB) to
    define application-level variables and global routines/functions. C# doesn't
    support modules, but you can do the same with static class members. In VB.NET you have both
    options, but modules are good because the caller code doesn't need to prefix the
    procedure name with the module name, as it must do with a static class's members instead. C#
     callers will see the module as a class with static members (at a lower level modules are
    implemented that way, in fact), so the compatibility is fully preserved.
    6.  VB.NET's ReDim statement allows you to change the dimension of an
    existing array and to maintain the current values. This is not directly possible with C#--you
    should create a new array with the new size and then copy the values from the old array
    to the new instance. Or you could use an ArrayList and when you're done adding
    elements you can use its ToArray method to get a real array.
    7.  VB.NET's Select statement is more flexible than C#'s switch statement,
     in that it allows you to specify intervals of values (Case 1 To 50) or other
    conditions (Case Is >10), while C# only allows you to use simple constants (you have to use
    the if statement if you need more flexible conditions). C#'s case blocks must also end with
    an explicit break statement.
    8.  VB.NET's Catch statement of a Try...Catch...Finally block is more
    flexible than the C#'s counterpart, in that it allows you to specify a further condition
    that must be met to have the exception being handled by that Catch block. For example, you
    can have something like the following in VB.NET:
    9.  VB.NET fully supports the structured exception handling, like C#, it
    is even more flexible as explained in the previous point. However, it also still
    supports the infamous On Error statement. Although it has a bad reputation, it may actually be
     useful in certain situations, when you need to resume the execution after the statement
    that caused the exception, and not just after all the statements of a Try...Catch...Finally
     block. This is not to suggest using the On Error option, structured exception handling
    is a better solution (in terms of performance as well) in many cases, just not
    always. The choice is always yours, and personally I like to have one more option than one  less.
    10.  VB.NET has the ^ operator to do operations with exponents, while C#
    doesn't have a counterpart for this operator. You necessarily must use the Math.Pow
    static method. Ok, this is not a very important feature, but it may make your code a bit
    shorter in math-intensive algorithms.
    11.  In VB.NET you can declare and create a new object instance with a
    single statement: Dim o As New MyObject, while in C# you must first declare a new object
    variable, and then instance it (even if you can still do this in the same line, as in
    MyObject o = new MyObject();). The VB.NET's way is faster to write, and keeps the lines
    12.  This point concerns VB.NET programming with Visual Studio .NET, so it
     is not really about the VB.NET language itself, but I feel it's a quite important
    point. When in C# you add a method to an existent class, you must recompile the project before
     seeing that new method in the list that the Intellisense pops up when you write the
    class instance name followed by a dot. Instead, in VB.NET the new member is immediately
    available in the list. Similarly, when you write invalid code in C#--such as referring to an
    invalid variable name, calling a non-existent method or passing a wrong number of
    arguments--the error is signaled only at compile time. Instead, in VB.Net the invalid code is
    immediately underlined in red, and you can correct it before compiling. This is
    because the VB.NET is compiled in background while you write it. This is very, very useful,
    but it also makes the code editor much slower than in C# because of the background work...
     so you must have a fast machine to really appreciate this feature, otherwise you'll be
    bothered by the slow editor!
    13.  VB.NET has the CType function and other casting operators that you
    can use instead of
    the Convert class, and that make the casting easier.
    14.  Instead of importing/including the same list of common namespace in
    all your source
    files, as you do in C#, in VB.NET you can define this list at project
    level, and add just
    the file-specific imports in the source files. This is very handy when
    you realize that
    you can remove an unused namespace or you have to add another one.
    However, I must say
    that if you need to import a certain source file later into another
    project, you might
    find yourself spending time wondering which project-level imports you
    need in the new
    project. This issue does not present in C#, of course, where all the
    imports are declared
    at the top of each file.
    15.  In a VB.NET Windows Forms project where you have a lot of forms you
    can set the startup
    forms from the project's Properties dialog, or set a Sub Main procedure
    as startup object.
    In C# you don't have this possibility, the startup form is always
    created and launched
    from a static Main procedure defined somewhere, typically in the first
    form class added by
    VS.NET. When you have a lot of forms and don't remember where the Main
    function is
    defined, and you want to change the startup form, you first have to find
     the Main
    procedure, and then you have to edit it, and possibly move it to an
    external class or the
    startup form class, if you want your code to be well organized.
    16.  VB.NET still supports the Declare statement you're used to from the
    previous version.
    C# doesn't have it and you must declare the signature of the API routine/function
     and then
    link it to its implementation using the DllImport attribute. VB.NET
    developers can use
    this attribute as well (and they should), but still keep the other
    possibility, which is
    useful especially when you're porting to .NET from existing VB code.
    17.  VB.NET still supports many VB functions, such as AppActivate, Shell,
    StrComp and others, that either don't have a direct .NET counterpart, or
     provide a quick
    shortcut to something that would require more code in C#.
    LVL 2

    Author Comment

    Thank you both.

    Write Comment

    Please enter a first name

    Please enter a last name

    We will never share this with anyone.

    Featured Post

    Highfive Gives IT Their Time Back

    Highfive is so simple that setting up every meeting room takes just minutes and every employee will be able to start or join a call from any room with ease. Never be called into a meeting just to get it started again. This is how video conferencing should work!

    After several hours of googling I could not gather any information on this topic. There are several ways of controlling the USB port connected to any storage device. The best example of that is by changing the registry value of "HKEY_LOCAL_MACHINE\S…
    Today I had a very interesting conundrum that had to get solved quickly. Needless to say, it wasn't resolved quickly because when we needed it we were very rushed, but as soon as the conference call was over and I took a step back I saw the correct …
    This is Part 3 in a 3-part series on Experts Exchange to discuss error handling in VBA code written for Excel. Part 1 of this series discussed basic error handling code using VBA.…
    This video discusses moving either the default database or any database to a new volume.

    846 members asked questions and received personalized solutions in the past 7 days.

    Join the community of 500,000 technology professionals and ask your questions.

    Join & Ask a Question

    Need Help in Real-Time?

    Connect with top rated Experts

    5 Experts available now in Live!

    Get 1:1 Help Now