So, What's New in the Visual Basic Upgrade Companion version 2.2?

11. December 2008 12:09 by Jaguilar in General  //  Tags: , , , ,   //   Comments (0)

As I mention in a post last week, we recently released version 2.2 of the Visual Basic Upgrade Companion. The previous version, 2.1, added some new things, but focused mostly on "under the covers" improvements, and fixing several issues reported with version 2.0. However, for this release, we do have several exciting new features that should make migrations from Visual Basic 6.0 go much smoother. Among these, we can mention:

Custom Mappings
The Visual Basic Upgrade Companion enables the user to define customized transformations for the upgrade process execution. This technique allows to implement coverage for non-supported legacy components and to enhance and fine-tune the existing support. I already covered Custom Maps on this post and you can read more about this on the Custom Maps page.

Data access - new flavors available
The Visual Basic Upgrade Companion converts the data access model on your VB6 application (ADO, DAO, RDO) to ADO.NET, using the either SQLClient data provider or the classes defined in the System.Data.Common namespace. Using the latter will allow your migrated application to connect with most major .NET database providers. Version 2.2 added support for the automated migration of DAO and RDO to ADO.NET, and greatly improved the migration of ADO to ADO.NET. More information here.

Naming conventions refactoring
This  feature  lets  the  end-user  migrate  his  Visual  Basic  6  code  to  VB.NET  or  C#  with  standard Naming Conventions.  This  feature  is  a compound of common naming conventions for .NET languages, and use  standard  coding  practices for  C# and VB.NET. You can find more information on this and the next feature in this page.

Renaming mechanism
The  renaming  feature changes  the name of an  identifier and all of  its  references  in order  to avoid conflicts with another name. Some of the conflicts solved by the VBUC are:

  • Keywords: The VBUC must rename the names that are the same as keywords from Visual Basic .NET and C#. Moreover,  the  VBUC  should  take  into  account  the  target  language  (Visual  Basic.NET  or  C#)  to recognize the keywords that apply for each case.
  • Case sensitive issues (C#): Visual  Basic  6  is  a  case  insensitive  language,  but  C#  is  not.  The  VBUC must  correct  the  name references used with different cases to the case used in the declaration.
  • Scope conflict: This is necessary when a Type declaration element has the same name as the type declaration. If  this case  is detected  the element declaration must be  renamed along with  the  references  to  this type element.
  • Conflicts with .NET classes: This section applies for Forms and UserControls, mainly, because they could declare some member names that are part of the corresponding class in .NET (in this case System.Windows.Forms.Form & System.Windows.Forms.UserControl).  These  members  must  be  renamed  in  order  to  avoid  any conflict.

User Controls and Custom Properties
In Visual Basic 6.0  user  controls  expose  their  programmer-defined  properties  in  the  property  list  on  the designer window. These user properties can be configured to be displayed in a specific category and based on  these settings. The Visual Basic Upgrade Companion can determine  the most appropriate type  and  settings  for  the  resulting  properties  to  have  functional  equivalence with  the  original VB6 user property. I plan on elaborating on this feature in a future blog post.

Visual Basic Upgrade Companion version 2.2 released!!

2. December 2008 19:56 by Jaguilar in General  //  Tags: , , , , , ,   //   Comments (0)

After several months of hard work, we are proud to announce the release of version 2.2 of the Visual Basic Upgrade Companion. This version includes significant enhancements to the tool, including:

  • Custom Maps: You can now define custom transformations for libraries that have somewhat similar interfaces. This should significantly speed up your migration projects if you are using third party controls that have a native .NET version or if you are already developing in .NET and wish to map methods from your VB6 code to your .NET code.
  • Legacy VB6 Data Access Models: for version 2.2 we now support the transformation of ADO, RDO and DAO to ADO.NET. This data access migration is implemented using the classes and interfaces from the System.Data.Common namespace, so you should be able to connect to any database using any ADO.NET data provider.
  • Support for additional third party libraries: We have enhanced the support for third party libraries, for which we both extended the coverage of the libraries we already supported and added additional libraries. The complete list can be found here.
  • Plus hundreds of bug fixes and code generation improvements based on the feedback from our clients and partners!

You can get more information on the tool on the Visual Basic Upgrade Companion web page. You can also read about our migration services, which have helped many companies to successfully take advantage of their current investments in VB6 by moving their applications to the .NET Framework in record time!

Alright, Visual Basic 6 Application run on Vista, but where's the IDE?

21. November 2008 10:07 by Jaguilar in General  //  Tags: , , , ,   //   Comments (0)

Do you remember this classic bit, a pretty bad joke from the end of the movie "Coming to America":

"A man goes into a restaurant, and he sits down, he's having a bowl of soup and he says to the waiter: "Waiter come taste the soup."
Waiter says: Is something wrong with the soup?
He says: Taste the soup.
Waiter says: Is there something wrong with the soup? Is the soup too hot?
He says: Will you taste the soup?
Waiter says: What's wrong, is the soup too cold?
He says: Will you just taste the soup?!
Waiter says: Alright, I'll taste the soup - where's the spoon??
Aha. Aha! ..."

Well, the thing is that this week, when I read this column over at Visual Studio Magazine, this line of dialog was the first thing that came into my mind. First of all, we have the soup: according to the Support Statement for Visual Basic 6.0 on Windows®Vista™and Windows®Server 2008™, the Visual Basic 6.0 runtime support files will be supported until at least 2018 (Windows Server 2008 came out in 27 February 2008):

Supported Runtime Files – Shipping in the OS: Key Visual Basic 6.0 runtime files, used in the majority of application scenarios, are shipping in and supported for the lifetime of Windows Vista or Windows Server 2008. This lifetime is five years of mainstream support and five years of extended support from the time that Windows Vista or Windows Server 2008 ships.  These files have been tested for compatibility as part of our testing of Visual Basic 6.0 applications running on Windows Vista.

Then, we have the spoon, taken from the same page:

The Visual Basic 6.0 IDE

The Visual Basic 6.0 IDE will be supported on Windows Vista and Windows Server 2008 as part of the Visual Basic 6.0 Extended Support policy until April 8, 2008.  Both the Windows and Visual Basic teams tested the Visual Basic 6.0 IDE on Windows Vista and Windows Server 2008.  This announcement does not change the support policy for the IDE.

So, even though you will be able to continue using your Visual Basic 6.0 applications, sooner or later you will need to either fix an issue found in one of them, or add new functionality that is required by your business. And when that day comes, you will face the harsh reality that the VB6.0 IDE is no longer supported. Even worst so, you have to jump through hoops in order to get it running. If you add the fact that we are probably going to see Windows 7 ship sooner rather than later, the prospect of being able to run your application but not fix it or enhance it in a supported platform becomes a real possibility. So make sure that you plan for a migration to the .NET Framework ahead of time - you don't want to hear anybody telling you "Aha. Aha!" if this were to happen.

Starting a Visual Basic to .NET migration with the Visual Basic Upgrade Companion in 5 Simple Steps

17. November 2008 05:23 by Jaguilar in General  //  Tags: , , , ,   //   Comments (0)

So you now have a license of the Visual Basic Upgrade Companion, you open it up, and you don't know what now to do. Well, here are 5 simple steps you can follow to get the most out of the migration:

  1. Read the "Getting Started" Guide: This is of course a no brainer, but well, we are all developers, and as such, we only read the manual when we reach a dead end ;). The Getting Started guide is installed alongside the Visual Basic Upgrade Companion, and you can launch it form the same program group in the start menu:
  2. Create a New Upgrade Solution: the first step for every migration will be to create a new VBUC Migration Solution. In it, you need to select the directory that holds your sources, select where you want the VBUC to generate the output .NET code, and the location of the binaries generated and use by the application. This last bit of information is very important, since the VBUC extracts information from the binaries in order to resolve the references between projects and create a VS.NET solution complete with references between the projects:
  3. Select the Target Language: One of the most significant advantages of using the Visual Basic Upgrade Companion is that it allows you to generate Visual Basic.NET or C# code directly. This can be selected using the combo box in the Upgrade Manager's UI:
  4. Create a Migration Profile: The Visual Basic Upgrade Companion gives a large degree of control to the end users on how the .NET code will be generated. In addition to the option of creating either C# or VB.NET code, there are also a large amount of transformations that can be turned on/off using the profile manager. Starting with version 2.2, the Profile Manager recognizes the components used in the application and adds a green checkmark to the features that apply transformations to those components. This simplifies profile creation and improves the quality of the generated code from the start:
  5. Select the Code Typing Mechanism: the VBUC is able to determine the data type for variables in the VB6.0 code that are either declared without type or as Variant. To do this, for each project included in the migration solution you can select three levels of typing: Full Typing, Local Typing or No Typing. Full Typing is the most accurate typing mechanism - it infers the type for the variables depending on how they are used throughout the project. This means that it needs to analyze the complete source code in order to make typing decisions, which slows the migration process and has higher memory consumption. Local Typing also infers data types but only within the current scope of the variable. And No Typing leaves the variables with the same data types from the VB6.0 code:

After going through these 5 steps, you will have an Upgrade Solution ready to go that will generate close to optimal code. The next step is just to hit the "Start" button and wait for the migration to finish:


Visual Basic 6.0 to C# Case Studies

11. November 2008 06:29 by Jaguilar in General  //  Tags: , , , ,   //   Comments (0)

A few days ago we posted some new case studies to our site. These case studies highlight the positive impression that the capabilities of the Visual Basic Upgrade Companion leave on our customers when we do Visual Basic 6.0 to C# migrations.

The first couple of them deal with a UK company called Vertex. We did two migration projects with them, one for a web-based application, and another one for a desktop application. Vertex had a very clear idea of how they wanted the migrated code to look like. We added custom rules to the VBUC in order to meet their highly technical requirements, so the VBUC would do most of the work and speed up the process. Click on the links to read the case studies for their Omiga application or for the Supervisor application.

The other one deals with a Texas-based company called HSI. By going with us they managed to move all their Visual Basic 6.0 code (including their data access and charting components) to native .NET code. They estimate that by using the Visual Basic Upgrade companion they saved about a year in development time and a lot of money. You can read the case study here.

Migrating Visual Basic 6.0 Optional Parameters to .NET

7. November 2008 05:53 by Jaguilar in General  //  Tags: ,   //   Comments (0)

In Visual Basic 6.0 you can specify optional parameters in a function or sub signature. This, however, isn't possible in .NET. In order to migrate code that uses this optional parameters, the Visual Basic Upgrade Companion creates different overload methods with all the possible combinations present in the method's signature. The following example will further explain this.

Take this declaration in VB6:

Public Function OptionSub(Optional ByVal param1 As String, Optional ByVal param2 As Integer, Optional ByVal param3 As String) As String
    OptionSub = param1 + param2 + param3
End Function

In the declaration, you see that you can call the function with 0, 1, 2 or 3 parameters. When running the code through the VBUC, you will get four different methods, with the different overload combinations, as shown below:

static public string OptionSub( string param1, int param2, string param3)

     return (Double.Parse(param1) + param2 + Double.Parse(param3)).ToString();

static public string OptionSub( string param1, int param2)

      return OptionSub(param1, param2, "");

static public string OptionSub( string param1)

      return OptionSub(param1, 0, "");

static public string OptionSub()

      return OptionSub("", 0, "");

The C# code above doesn't have any change applied to it after it comes out of the VBUC. There may be other ways around this problem, such as using parameter arrays in C#, but that would be more complex in scenarios like when mixing different data types (as seen above).

Power to the People: Custom Maps in the Visual Basic Upgrade Companion

5. November 2008 12:19 by Jaguilar in General  //  Tags: ,   //   Comments (0)

Right now we are entering the final stages of testing for the release of the next version of the Visual Basic Upgrade Companion (VBUC). This release is scheduled for sometime within the next month.

One of the most exiting new features of this new release is the addition of Custom Maps. Custom Maps are simple translation rules that can be added to the VBUC so they are applied during the automated migration. This allows end users to fine tune specific mappings so that they better suit a particular application. Or you can actually create mappings for third party COM controls that you use, as long as the APIs for the source and target controls are similar.

The VBUC will include an interface for you to edit these maps:

Also, once you create the map, you can select them using the Profile Editor:

Custom Maps add a great deal of flexibility to the tool. Even though only simple mappings are allowed (simple as in one-to-one mappings, currently it doesn't allow you to add new code before or after the mapped element), this feature allows end users edit, modify or delete any transformation included, and to add your own. By doing this, you can have the VBUC do more work in an automated fashion, freeing up developer's time and speeding up the migration process even more.

Interesting Behavior of TabIndex in Migrated Applications

5. November 2008 11:14 by Jaguilar in General  //  Tags: ,   //   Comments (0)

While working on a migration project recently, we found a very particular behavior of the TabIndex property when migrating from Visual Basic 6.0 to .NET. It is as follows:

In VB6, we have the following form: (TabIndexes in Red)

Note that TabIndex 0 and 10 correspond to the Frames Frame1 and Frame2. If you stand on the textbox Text1, and start pressing the tab key, it will go through all the controls in the following order (based on the TabIndex): 1->2->3->4->5->6->-7>8->9.

After the migration, we have the same form but in .NET. We still keep the same TabIndex for the components, as shown below:

In this case TabIndex 0 and 10 correspond to the GroupBox Frame1 and Frame2. When going through the control in .NET, however, if you start pressing the tab key, it will use the following order: 1->2->3->7>8->9->4->5->6. As you can see, it first goes through the buttons (7, 8 and 9) instead of going through the textboxes. This requires an incredibly easy fix (just changing the TabIndex on the GroupBox) to replicate the behavior from VB6, but I thought it would be interesting to throw this one out there. This is one of the scenarios where there is not much that the VBUC can do (it is setting the properties correctly on the migration). It is just a difference in behavior between VB6 and .NET for which a manual change IS necessary.

Error 2869 when trying to install the Visual Basic Upgrade Companion

30. June 2008 11:17 by Jaguilar in General  //  Tags: , ,   //   Comments (0)

Every once in a while when trying to install the VBUC you may run into error 2869:

Error VBUC no Visual Studio installed pre-ORCA

This error, as you can see, doesn't really give you any insight on what may be wrong with the installation. Well, thanks to this blog post, here is a quick process you can follow to troubleshoot the installation and get the actual error that is being masked:

  1. First, you need to have ORCA installed on your system. ORCA is available as part of the Windows SDK.
  2. Once you have it installed, find the file setup.msi from the VBUC installer package. Right click on it and select "Edit with ORCA" from the popup menu:

    Error VBUC no Visual Studio installed Edit with ORCA

  3. Once in ORCA, in the Table panel, scroll down and highlight the "Error" line. On the right-hand panel right-click and select Add Row:

    Error VBUC no Visual Studio installed ORCA Add Row

  4. In the panel that is displayed, enter "1001" for the Error, and "Error [1]:[2]" on the Message. Press OK and the table should look like the following:

    Error VBUC no Visual Studio installed ORCA

  5. Once you are done editing, save the file in ORCA, close it, and launch the installer. You will now get a more explanatory error:

    Error VBUC no Visual Studio installed

As you can see, in this case at least, the error was caused by not having one of the requirements, Visual Studio (2005 or 2008) installed. This only applies to the current version of the VBUC, as the next version will have these issues with the error messages solved. I still wanted to put this out there, as I got some feedback on it last week.

VBUC 2.0 Feature Spotlight: Structured Error Handling in C#

17. June 2008 05:56 by Jaguilar in General  //  Tags: ,   //   Comments (0)

The latest release of the Visual Basic Upgrade Companion improves the support for moving from VB6.0's On Error Statements to C# structured error handling, using try/catch blocks. In this post I will cover a couple of examples on how this transformation is performed.

First of, this is something that you may not need/want in your application, so this is a features managed through the Migration Profile of the application. In order to enable it, in the Profile, make sure the "On Error To Try Catch" feature is enabled.


Now let's get started with the examples.

On Error Resume Next

First of, let's cover one of the most frustrating statements to migrate from VB6.0: the dreaded On Error Resume Next. This statement tells VB6.0 to basically ignore errors and continue execution no matter what. VB6.0 can recover from some errors, so an application can continue without being affected. These same errors, however, can cause an exception in .NET, or may leave the application in an inconsistent state.

Now let's look at a code example in VB6.0:

Private Sub bttnOK_Click() 
On Error Resume Next 
    MsgBox ("Assume this line throws an error") 
End Sub 

The VBUC would then leave it as follows in C#:

private void  bttnOK_Click( Object eventSender,  EventArgs eventArgs)
        //UPGRADE_TODO: (1069) Error handling statement 
(On Error Resume Next) was converted to a complex pattern which 
might not be equivalent to the original.
                MessageBox.Show("Assume this line throws an error", 
        catch (Exception exc)
            throw new Exception(
		"Migration Exception: The 
		following exception could be handled in a different 
		way after the conversion: " + exc.Message);

Because of this, the decision was made to wrap the code that is in the scope of the On Error Resume Next statement on a try/catch block. This is likely the way it would be implement in a "native" .NET way, as there is no real equivalent functionality to tell C# to ignore errors and continue. Also, the VBUC adds a comment (an UPGRADE_TODO), so the developer can review the scenario and make a judgement call on wether to leave it as it is, or change it in some way. Most of the time, the try/catch block can be limited to just one line of code, but that modification requires some manual intervention. Still, it is easier when there is something already there.

On Error GoTo <label>

The other common scenario is to have a more structured approach to error handling. This can be illustrated with the following code snippet:

Private Sub bttnCancel_Click() 
On Error GoTo errorHandler 

MsgBox ("Assume this line throws an error") 

    Exit Sub 
    MsgBox ("An error was caught") 
    GoTo exitSub 
End Sub

Since this code is using a pattern that is very similar to what the try/catch statement would do, the VBUC is able to identify the pattern and move it to the appropriate try/catch block:

private void  bttnCancel_Click( Object eventSender,  EventArgs eventArgs)
     MessageBox.Show("Assume this line throws an error", Application.ProductName);
     MessageBox.Show("An error was caught", Application.ProductName);

As you can see, the functionality of this type of pattern is replicated completely, maintaining complete functional equivalence with the VB6.0 code.

Overall, the support for converting On Error statements from VB6.0 into the proper structured error handling structures in C# has come a long way. It is now very robust and supports the most commonly used patterns. So, unless you are using some strange spaghetti code or have a very peculiar way of doing things, the VBUC will be able to translate most scenarios without issues. Some of them, as mentioned, may still required human intervention, but let's face it - using On Error Resume Next shouldn't really be allowed in any programming language!! ;-)