Want to win a PS4? Go Premium and enter to win our High-Tech Treats giveaway. Enter to Win

x
?
Solved

VB.NET or C#.NET

Posted on 2004-10-22
3
Medium Priority
?
531 Views
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 C#.net 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.
0
Comment
Question by:phpisthefuture
[X]
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
3 Comments
 
LVL 20

Assisted Solution

by:jitganguly
jitganguly earned 400 total points
ID: 12383771
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 VB.net than C#. I am from VB background, but I use C# and frankly it took me little extra time to learn ans still learning. VB.net would have been my ideal choice, but I wanted to learn C#
0
 
LVL 28

Accepted Solution

by:
iboutchkine earned 1600 total points
ID: 12384185
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.

================================================
Productivity
============
- 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
Framework)
- 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

Technology
==========
- 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
Linux http://www.go-mono.com)

Knowledge-reuse
===============
- 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
VB.NET!

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 http://archive.devx.com/devxpress/gurl.asp?i=1X8968461X94458 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
value
      DoSomething(-1)
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
shorter.
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,
PrevInstance,
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#.
0
 
LVL 2

Author Comment

by:phpisthefuture
ID: 12384560
Thank you both.
0

Featured Post

Get your Disaster Recovery as a Service basics

Disaster Recovery as a Service is one go-to solution that revolutionizes DR planning. Implementing DRaaS could be an efficient process, easily accessible to non-DR experts. Learn about monitoring, testing, executing failovers and failbacks to ensure a "healthy" DR environment.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

More often than not, we developers are confronted with a need: a need to make some kind of magic happen via code. Whether it is for a client, for the boss, or for our own personal projects, the need must be satisfied. Most of the time, the Framework…
This article shows how to deploy dynamic backgrounds to computers depending on the aspect ratio of display
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. http://www.experts-exchange.com/videos/1478/Excel-Error-Handlin…
In this video, Percona Solution Engineer Rick Golba discuss how (and why) you implement high availability in a database environment. To discuss how Percona Consulting can help with your design and architecture needs for your database and infrastr…

597 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