C# & VB.NET Conversion Pocket Reference

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

If you are anything like me, the following is a common scenario: You are writing some code not in the language you traditionally use. Although you know a needed command in your language of choice, the keyword in the language you are using is not even remotely similar, and you can't even think of a word to type in the help file to try to get it. You want to be able to flip through a short book that has your keyword in it, along with the equivalent way of coding it in the new language you are using. This book attempts to fill that need.

This book—as well as my recognition of the need for it—grew out of my own experience. I was teaching courses on VB.NET exclusively. Then one day, I was asked to teach a C# course. It was in front of about 25 C# students that I figured out, the hard way, that knowing VB.NET does not mean you automatically know C# (and I even knew C++).

Microsoft has advertised that the .NET runtime is language agnostic, and that C# and VB.NET are so close that switching between the two is really nothing more than choosing between semicolons and Dims. That is true to a certain extent. However, during that week in front of the firing squad, I discovered that there were a lot of differences between the two, some really obvious, and some more subtle.

The differences, it seemed to me, occur in three main areas: syntax, object-oriented principles, and the Visual Studio .NET IDE. Syntax concerns the statements and language elements; you say tomato, I say toe-mah-toe. Object-oriented differences are more subtle, and concern differences in implementation and feature sets between the two languages. They concern things such as inheritance and method overloading. IDE differences include things like compiler settings, which are attributes you set through the IDE that have different effects depending on what language you use. There is also a fourth area of difference: language features that are present in one language but have no equivalent in the other. These unique language features are also covered in this book.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

If you are anything like me, the following is a common scenario: You are writing some code not in the language you traditionally use. Although you know a needed command in your language of choice, the keyword in the language you are using is not even remotely similar, and you can't even think of a word to type in the help file to try to get it. You want to be able to flip through a short book that has your keyword in it, along with the equivalent way of coding it in the new language you are using. This book attempts to fill that need.

This book—as well as my recognition of the need for it—grew out of my own experience. I was teaching courses on VB.NET exclusively. Then one day, I was asked to teach a C# course. It was in front of about 25 C# students that I figured out, the hard way, that knowing VB.NET does not mean you automatically know C# (and I even knew C++).

Microsoft has advertised that the .NET runtime is language agnostic, and that C# and VB.NET are so close that switching between the two is really nothing more than choosing between semicolons and Dims. That is true to a certain extent. However, during that week in front of the firing squad, I discovered that there were a lot of differences between the two, some really obvious, and some more subtle.

The differences, it seemed to me, occur in three main areas: syntax, object-oriented principles, and the Visual Studio .NET IDE. Syntax concerns the statements and language elements; you say tomato, I say toe-mah-toe. Object-oriented differences are more subtle, and concern differences in implementation and feature sets between the two languages. They concern things such as inheritance and method overloading. IDE differences include things like compiler settings, which are attributes you set through the IDE that have different effects depending on what language you use. There is also a fourth area of difference: language features that are present in one language but have no equivalent in the other. These unique language features are also covered in this book.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Syntax differences are the most common differences that we think about when comparing two languages. Syntax differences refer to differences in the keywords and format of statements used to perform identical tasks. For instance, in C#, a language statement is terminated with a semicolon; in VB, a language statement is terminated with the carriage return/linefeed character sequence. In this section, we'll survey the syntactical differences between VB.NET and C#.

One major difference between the languages is that C# is case sensitive, while VB.NET is not. That means that while it is okay in VB.NET to write:

system.console.writeline("hello world")

(all in lowercase), in C# that line results in an error. The correct way to invoke this command in C# is:

System.Console.WriteLine("hello world");

Both C# and VB.NET compile to a language known as Intermediate Language (IL). Interestingly, IL is case sensitive, which means that VB must convert lines at compile time to match the correct casing of the original command at the IL level.

A side effect of not being case sensitive is that at times, the compiler may not match casing correctly to the original declaration of a function, resulting in incorrect behavior. For example:

               
                  
                  
                     
                  
               
Class Account
   Overloads Function toString( _
      ByVal Format As String) As String
      Return "My String with Format"
   End Function
  
   Overloads Overrides Function toString(  ) As String
      Return "My String"
   End Function
End Class
  
Module App
   Sub Main(  )
      Dim acct As Object = New Account(  )
      System.Console.WriteLine(acct.ToString(  ))
   End Sub
End Module

This code has strange results in VB.NET. The VB compiler cases the toString method incorrectly to match the first definition of toString in the Account class (with lowercase T), rather than matching both definitions to the one inherited from System.Object (with capital T). The end result is that toString does not override the ToString method in the base class, and the toString method is never called. This example shows the complexity of having a case-insensitive language in a case-sensitive world.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Unlike syntactic differences, which reflect merely a difference in keywords and format, object-oriented differences between C# and VB stem from differences in implementation between the two languages.

Both C# and VB can use class-based inheritance. In .NET, a class can derive from at most one other class; in other words, the system only allows single inheritance. However, a class can implement multiple interfaces. Both languages have different semantics for class inheritance and interface implementation. (Both require, though, that the inherited class be listed before any implemented interfaces.)

To use class-based inheritance in C#, list the class you would like to inherit from immediately after the derived class name, separated by a colon, as in the following example:

               
                  
                  
                     
                  
               
class Account
{
}
class Checking : Account
{
}

In this example, the Checking class derives from the Account class.

Class-based inheritance in VB is done with the Inherits keyword:

               
                  
                  
                     
                  
               
Class Account
End Class
  
Class Checking 
    Inherits Account
End Class

Often, a colon is used to combine the declaration for the class with the Inherits statement to make the line of code look more C#-like:

               
                  
                  
                     
                  
               
Class Checking : Inherits Account
End Class

Using Inherits in this fashion is the same as moving the Inherits clause to the next line without a colon.

Overloading means that several methods have the same name but different signatures. Method overloading differs slightly between the languages. Method overloading in C# and in VB.NET does not require a keyword; you simply add another method with the same name, as in the following example:

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

This section concerns primarily differences in the way that Visual Studio configures projects in C# and VB. These differences in turn often affect the operation of each language's compiler.

Whenever you generate a new project, each language adds either an AssemblyInfo.vb (for VB) or an AssemblyInfo.cs file (for C#). This file contains attributes for the assembly. Think of the assembly as the project. Assembly attributes are things like Title, Description, Version Number, etc. for the resulting EXE or DLL. Each language puts slightly different attributes in each file. The following code list shows each C# attribute, followed by the VB.NET equivalent:

[assembly: AssemblyTitle("")] //C#
<Assembly: AssemblyTitle("")> 'VB
  
[assembly: AssemblyDescription("")] //C#
<Assembly: AssemblyDescription("")> 'VB
  
[assembly: AssemblyConfiguration("")] //C#
               'VB .NET does not add this attribute

[assembly: AssemblyCompany("")] //C#
<Assembly: AssemblyCompany("")> 'VB
  
[assembly: AssemblyProduct("")] //C#
<Assembly: AssemblyProduct("")> 'VB
  
[assembly: AssemblyCopyright("")] //C#
<Assembly: AssemblyCopyright("")> 'VB
  
[assembly: AssemblyTrademark("")] //C#
<Assembly: AssemblyTrademark("")> 'VB
  
[assembly: AssemblyCulture("")]  //C#
               'VB does not add this attribute

               //C# does not add this attribute
               <Assembly:CLSCompliant(True)> 'VB

               //C# does not add this attribute
               <Assembly: Guid("xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx")>  'VB

[assembly: AssemblyVersion("1.0.*")] //C#
<Assembly: AssemblyVersion("1.0.*")> 'VB
  
[assembly: AssemblyDelaySign(false)] //C#
               'VB does not add this attribute
               
               [assembly: AssemblyKeyFile("")] //C#
               'VB does not add this attribute
               
               [assembly: AssemblyKeyName("")] //C#
               'VB does not add this attribute

Let's discuss the attributes that are not added by default in both languages.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

This section covers features that are specific to each language. Throughout the book I have been pointing out things that are in one language and not in the other if the other language at least has a feature that remotely resembles that of the first. This section covers things in each language that are not really available in the other.

Perhaps the biggest difference between C# and VB.NET is that C# enables developers to write blocks of unsafe code. Unsafe blocks (or unmanaged blocks) are mainly used to access API functions or COM functions that require pointers and enable C# developers to manipulate memory directly through pointers. In C#, it is illegal to use pointers unless the code is inside an unsafe block.

Most of the time, C# developers will not use unsafe blocks, since unsafe code can't be verified and therefore requires much higher security rights than code that can be verified to be safe. The following shows an example of unsafe code:

               
                  
                  
                     
                  
               
class Class1
{
   static unsafe void Main(string[] args)
   {
      //who says strings cannot be changed
      string sName = "Joseph Mojica";
        
      fixed (char *Temp = sName)
      {
         char *ch = Temp;
         ch += 4;
         *ch = (char)0;
         ch += 1;
         *ch = (char)0;
      }
  
      System.Console.WriteLine(sName);
   }
}

This code accesses the buffer of a string variable directly and changes two characters. Normally, strings are immutable, but with unsafe code, you can manipulate memory directly. Notice that the function needs to be marked as unsafe. Also notice the use of the fixed keyword. fixed pins a variable to a certain location of memory so that if garbage collection occurs, the collector will not move the contents of memory that the variable points to to another location.

Because .NET reclaims memory using garbage collection, an object may not be released for a while, even if there are no variables pointing to it. Sometimes, however, it is good to deallocate expensive resources right away rather than waiting for the garbage collector. A good example of this is an ADO.NET Connection object, which potentially keeps a handle to a SQL Server connection. Connections are expensive resources and should be reclaimed as soon as possible. For that reason, the .NET framework defines the

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Table of Contents