• INDEX VB TO NET
• MIGRATION GUIDE
• CHAPTER 2

What not to do in a VBUC migration project?

Having a tool like the VBUC, a compiling VB6 code and a source environment set is not all that is needed to ensure success in a migration project from VB6 code to .NET. This entry will describe a list of thing that SHOULD NOT be done during the project.

Avoid Inconsistent Green Code Generation

The green-code is the direct output generated by the VBUC tool after converting VB6 code to .NET without any manual change.

The quality of this code and the way specific patterns or components are migrated rely on the configuration of the source environment, the completeness of the source code and the Upgrade Options (settings) indicated on the VBUC.

If the code to be migrated consists of different VB6 projects, then, configure a single Upgrade Solution that include all projects required to be migrated. In this way you'll make sure to select the same Upgrade Options for the entire code.

Avoid performing different migrations for different portions of the source code.

NOTE: If you still need to do that, make sure the same Upgrade Options are used in every migration.

 

Important: The green code should be consistent. If you fail to have a consistent green code this will increase the effort needed to stabilize the code which implied more costs (more time and more money).

Re-architecture of the application should be done after the Migration Process

Avoid making more changes to the application before getting the converted code to functional equivalence (FE).

Making changes before FE introduces risk and reduces the changes of success.

Once your converted application has reached functional equivalence it will be a better time to start thinking about major changes.

If there is still a need to introduce some changes or re-architecture then:

• take some time to analyze the changes that will be performed.
• make a plan to apply those changes in a systematic and consistent way.
• try to limit the scope of those changes.

Reduce Manual changes

In most of the migrated projects manual effort is needed to get the code to functional equivalence. Make sure to follow some rules before modifying the code:

• The fewer manual changes, the quicker to get a functional code soon.
• Before changing a migrated line, be analytical and economical. Make sure to answers questions like the following before you introduce those changes:
  • Is really this modification needed? (For example formatting, name convention changes, are things that can wait until the code is working, making those changes may introduce unnoticed different behaviors or make the code hard to track to its source)
  • Is this line of code the right place to introduce a modification?
  • Is this modification needed in several places? Is there any way to make this less massive? Perhaps think about general solutions.

The above questions require the person to introduce changes to have great abstraction capabilities.

When the above rules are not accomplished, different errors can be committed to the code. Avoid them:

1. The same problem solved in different ways (by different people)

2. Fix (supposedly) a compilation error by creating potential runtime exceptions
   VB6
   x = <recordset>(EnumType.enumMember)

   Note: EnumType.EnumMember is an enum

   Green Code C#
   x= <recordsethelper>[EnumType.EnumMember];

   The <recordsethelper> indexer property can be either a column-index or a column-name, so casting is needed in the above case. Given EnumType.EnumMember is an enum value, then the casting to int is needed.

   Wrong fix
   x= <recordsethelper>[EnumType.EnumMember.ToString()];

   Correct fix
   x= <recordsethelper>[Convert.ToInt32(EnumType.EnumMember)];
   or
   Correct fix
   x= <recordsethelper>[(int)EnumType.EnumMember];

3. Unneeded manual changes.

   Consider the following two lines of code:
   if (Convert.ToString(iteration_row["Name"]) != "" &&
    !Convert.IsDBNull(iteration_row["Name"]))

 if (Convert.ToString(iteration_row["Name"]) != "" &&
    !DBNull.Value.Equals(iteration_row["Name"]))

The former is generated by the VBUC and the latter is a manual modification of that line: An irrelevant change that only increases the number of manual changes and does not provide any gain to the code.

4. Change the application logic.

For instance, the migrated code has the following if-condition:

if (!rs.EOF)

and a manual change modifies the condition to:

if (rs.EOF)

Summary

Before starting a migration project, read and understand the Mobilize migration methodology is a key part of the project. Make sure to follow the suggested steps and avoid start making manual changes in your migrated code without understanding how and why the .NET code was generated.

Download VBUC Free Trial

It's time to eradicate VB6

8 Proven Tips for
Planning a Successful Migration