As IT costs increase and budgets decrease, you're pressed to make your code do more. Many vendors are producing applications to extend your application code by performing some type of conversion process, so the code works in more than one environment. Elegance Technologies produces C-Sharpener for VB, which promises to convert your Visual Basic code into C#.

Of course, the first question is why you should convert code from one language to another. Many consultants already know the answer: clients use a variety of languages to support their systems, and the consultant is normally responsible for producing code in their language. Unless you want to reinvent the wheel for every language you use, you need some way to convert the code after you write it the first time. Products like C-Sharpener fulfill this need.

However, C-Sharpener is important in other environments, as well. As companies merge, the IT department might find itself trying to maintain application code in more than one language. By converting the code to a single language (or, at least, reducing the number of languages when complete conversion isn't possible), an IT department can greatly reduce costs. However, conversion can quickly become a mind bogglingly difficult task without the proper tools. Again, you really need something like C-Sharpener to perform the task.

But should you use C-Sharpener... or something else? I took a close look at its capabilities, and I have a mixed opinion.

Performing a Conversion

After installing the product and going through the tutorial (I'll cover those details at the end of this article), I tried converting a few Visual Basic projects. The first project was admittedly easy; it consisted of a few dialog boxes and pure .NET code for a utility program. I wasn't surprised that the conversion was 100% correct.

The tutorial doesn't tell you to close the VB project before you open the C# project, but I found that this was the case during my testing. I was a little surprised about the time required to perform the conversion. Even a simple example required more than a minute to complete the task — admittedly not a long time, but Listing 1 shows the code I converted.

Listing 1: A Very Simple Visual Basic Application

Private Sub btnTest_Click(ByVal sender As System.Object, _
                          ByVal e As System.EventArgs) _
                          Handles btnTest.Click

   Dim eLog As EventLog           ' Holds the event log reference.
   Dim eLogEntry As EventLogEntry ' A single entry.

   ' If you want to use an existing log, simply register it
   ' as the destination. Generally, you have access to the
   ' application, security, and system logs.
   eLog = New EventLog("System")

   ' However, if you want to create a special log, then you need
   ' to register an event source first (as you already did in your
   ' example code).
   If (Not eLog.SourceExists("MyEventSource")) Then

      ' Create the new event source.
      eLog.CreateEventSource("MyEventSource", "MySpecialLog", ".")

   End If

   ' Register the new event source.
   eLog = New EventLog("MySpecialLog")
   eLog.Source = "MyEventSource"

   ' Create an entry.
   eLog.WriteEntry("MyEventSource", _
                   "Special Message", _
                   EventLogEntryType.Information, _
                   12, _
                   22)
End Sub

As you can see, this is a very simple application; it writes an event log entry. A large application could require a lot of time to convert. The converted file contains a few oddities, but it works as promised. Listing 2 shows the conversion.

Listing 2: Converted Visual Basic Application

private void btnTest_Click( System.Object sender, _
                                 System.EventArgs e ) { 
    
    EventLog eLog = null; //  Holds the event log reference.
    EventLogEntry eLogEntry = null; //  A single entry.
    
    //  If you want to use an existing log, simply register it
    //  as the destination. Generally, you have access to the
    //  application, security, and system logs.
    eLog = new EventLog( "System" ); 
    
    //  However, to create a special log, then you need to
    //  register an event source first (as you already did in
    //  your example code).
    if ( ( !( EventLog.SourceExists( "MyEventSource" ) ) ) ) { 
        
        //  Create the new event source.
        EventLog.CreateEventSource( "MyEventSource", 
                                    "MySpecialLog", "." ); 
        
    } 
    
    //  Register the new event source.
    eLog = new EventLog( "MySpecialLog" ); 
    eLog.Source = "MyEventSource"; 
    
    //  Create an entry.
    EventLog.WriteEntry( "MyEventSource", 
                         "Special Message",
                         EventLogEntryType.Information, 12, 22 ); 
} 

Everything seems straightforward, but the If statement seems to include an excessive number of parenthesis. Manually converting the code would have resulted in an If statement like this:

if (!EventLog.SourceExists("MyEventSource"))

Imagine a complex application that includes a lot of nested conditional code. The output from C-Sharpener could very well become unreadable and perhaps unusable at some point. Even so, this is a minor nit considering the fact the output does work without modification and is readable enough that someone could clean it up without too many problems.

After converting a few more applications, I looked at the Windows generated code and the other code that most developers don't really think about (because it isn't something they have written). Imagine my surprise when I found this using statement in the C# code.

using Microsoft.VisualBasic;

Commenting out this code didn't cause the application to fail. In fact, removing the Visual Basic reference didn't cause problems, either. You might find that you need to perform cleanup of this sort after the conversion. In this case, I managed to reduce the footprint of the converted application considerably by removing elements I didn't need. Carefully test the application, however, to ensure you don't remove too much.