The Visual Basic Upgrade Process

A successful and efficient Visual Basic upgrade process is best achieved by applying proven procedures. From careful preparation to final deployment of the application, chapter 4 describes the main steps of the migration project, as well as common Visual Basic to .NET upgrade issues and how to get the most out of the upgrade tools, including the Visual Basic Upgrade Assessment tool, the Visual Basic Code Advisor and of course, the Visual Basic Upgrade Wizard. Following the VB upgrade project steps and using the tools adequately will help you save time and effort, in order to ensure your applications are upgraded in the most efficient way possible.

• What are the basic task groups involved in an upgrade project?
• What is the application preparation stage?
• What is the application upgrade stage?
• What is the application testing and debugging stage?
• Why is it so important to create an upgrade procedure log?
• What are the main environment aspects that affect the upgrade process?
• How does the amount of memory available affect the upgrade process?
• When preparing for an upgrade process, what aspects of the original applications should be considered?
• Are there any tools I can use to for the preparation of internal aspects of the application to be upgraded?
• What does the Visual Basic 6.0 Upgrade Assessment Tool do?
• What is the Visual Basic 6.0 Code Advisor?
• What kinds of predetermined rules can the Visual Basic Code Advisor detect?
• What should I do about the components of code fragments that are no longer used in the application to be upgraded?
• Why should I have a resource inventory of the application to be upgraded?
• How can I verify that the source code is syntactically correct?
• In upgrading an application, what does ‘dependency’ mean?
• What is the purpose of performing a partial test upgrade of the application?
• What are the most common automated upgrade issues and how can I solve them?
• What steps should I execute to upgrade an application by using the Visual Basic Upgrade Wizard?
• How do I run the upgraded application?
• What happens when the upgrade tool is executed from the command line?
• What are the main issues that might occur during the upgrade wizard execution?
• What is the most common error reported by the upgrade wizard in typical Visual Basic 6.0 applications?
• What are the main issues that might appear in the upgrade report and how should I address them?
• What do I do about run-time errors?
• What are the most common upgrade issues that produce run-time errors?

What are the basic task groups involved in an upgrade project?

The steps involved in an upgrade project can be divided in the following task groups:

1. Application preparation
2.  Application upgrade
3. Application testing and debugging

These task groups require specialized skills and experience. The tasks included in each group can be executed with a certain level of parallelism, depending on the availability and specialization of resources needed.

What is the application preparation stage?

The application preparation can be summarized through the following inputs and outputs per steps:

a. Development environment preparation 
Input: Software development installers, third party component installers 
Output: A fully configured application development environment that corresponds to the application to be upgraded.

b. Upgrade tool preparation 
Input: Upgrade wizard installer, installers for the analysis tools.
Output: A fully configured system where the original application can run.

c. Obtaining the application resource inventory 
Input: Available information about the specifications and design of the original application. 
Output: Catalogue of documentation useful for upgrade purposes.

d. Compilation verification 
Input: The original Visual Basic 6.0 application in a correctly configured system. 
Output: System where the original application can be compiled, debugged, and executed.

e. Project upgrade order definition 
Input: Original source code. 
Output: An analysis of the application component dependencies based on analysis tools that can be used to plan the upgrade order of the different components.

f. Reviewing the upgrade wizard report 
Input: Upgrade wizard report for a partial test upgrade of the original application.
Output: Detection of computing resource problems and estimation of upgrade effort.

What is the application upgrade stage?

The application upgrade, including inputs and outputs where applicable, can be summarized as follows:

a. Execution of the Visual Basic Upgrade Wizard 
Input: Original Visual Basic 6.0 source code and upgrade system. 
Output: Initial upgraded application code base in Visual Basic .NET; this code base will likely contain upgrade issues that will later need to be addressed.

b. Verifying the progress of the upgrade 
This is a control step that verifies the correct execution of the upgrade wizard.

c. Upgrade wizard execution error correction 
This is a corrective step that can be applied when the upgrade wizard execution experiences problems.

d. Completing the upgrade with manual changes 
Input: Initial upgraded application code base in Visual Basic .NET 
Output: An upgraded Visual Basic .NET application that can be compiled.

What is the application testing and debugging stage?

The application testing and debugging stage consists in the following two steps:

a. Original test cases execution 
Input: An upgraded Visual Basic .NET application that can be compiled. 
Output: List of broken test cases and run-time bugs detected in the application.

b. Fixing run-time errors 
Input: An upgraded Visual Basic .NET application that can be compiled. 
Output: An upgraded Visual Basic .NET application that can be correctly run.

Why is it so important to create an upgrade procedure log?

Because this document, which is meant to include the products of each upgrade step, component dependency relationships and upgrade order, will provide you with a clear view of the process, allowing you to plan and measure the effort required for the future steps of the upgrade process. It will also be useful as a base for future upgrade projects.

What are the main environment aspects that affect the upgrade process?

There are two main environment aspect types that affect the upgrade process:

• The first aspect type, system resources, affects the speed of the upgrade process.
• The second environment aspect type, external dependencies, affects the normal execution and termination of the upgrade wizard. It will produce exceptions whenever necessary components are not present on the computer where the upgrade process is executed.

How does the amount of memory available affect the upgrade process?

The amount of memory available for the upgrade process will dramatically affect its speed. The minimum memory size recommended for a computer on which the upgrade wizard will be applied is 512 MB. The amount of memory should grow according to the size and complexity of the application. For example, Visual Basic 6.0 applications with more than 100,000 lines of code will require a minimum of 1 GB of memory to be upgraded. If the size of the application is millions of lines of code, a computer with 2 to 3 GB of memory should be used.

When preparing for an upgrade process, what aspects of the original applications should be considered?

Preparation for an upgrade process involves the following three areas that consider different aspects of the original application:

• Preparation of the upgrade wizard and external aspects of the application. This area includes the setup of all necessary tools for development and upgrade.
• Evaluation of the application. In this area of preparation, the application is evaluated to assess its composition and the possible difficulties that may arise when the upgrade process has been applied. The effort and cost estimation will be generated before the actual upgrade. This aspect of preparation is assisted by various tools, including the Visual Basic 6.0 Assessment Tool.
• Adjustment of the original application. In this area of preparation, adjustments are made to the original application to facilitate the upgrade process. These changes can be made to increase the automatic work done by the upgrade wizard and to reduce the manual completion tasks that are necessary after the automatic process. These changes are based on the initial assessment and general advice that can be obtained from different sources such as documentation and advisor tools.

Are there any tools I can use to for the preparation of internal aspects of the application to be upgraded?

Yes, and have proven to be extremely useful to assess the size and complexity of the application to be upgraded and to assist the developer in the changes that need to be made. These tools are the Visual Basic 6.0 Upgrade Assessment Tool and the Visual Basic 6.0 Code Advisor.

What does the Visual Basic 6.0 Upgrade Assessment Tool do?

The Visual Basic 6.0 Upgrade Assessment Tool, built by ArtinSoft, analyzes Visual Basic 6.0 source code and generates extensive information about an application. The tool can analyze multiple project files at the same time. This allows a user to select them individually, by groups, or by searching all .vbp files in a directory and its subdirectories. The tool has a weights file that can be used to assign a complexity value to each upgrade issue and generate customizable effort estimation data.

The assessment tool also generates different types of reports with application statistics and upgrade issues that can be used to estimate the upgrade effort.

What is the Visual Basic 6.0 Code Advisor?

The Visual Basic 6.0 Code Advisor is a Visual Basic 6.0 add-in that can be used to review the source code of an application. This tool helps the developer to ensure that the application meets predetermined coding standards. The coding standards are based on best practices developed by Microsoft to produce robust and easy-to-maintain code.

What kinds of predetermined rules can the Visual Basic Code Advisor detect?

The following list shows a sample of the predetermined rules that are detected by this tool:

• Late binding of variant object. An object is late-bound when it is assigned to variable declared to be of type Object. Objects of this type can hold references to any object. When the Visual Basic Upgrade Wizard upgrades a variable whose type is Object, it cannot identify the specific type of the variable, and none of the accesses to the corresponding class members are upgraded. This problem can be fixed by using specific types in the declaration of all variables. This is enforced using the directive Option Strict On. The Visual Basic 6.0 Code Advisor detects undeclared variables and suggests the developer use Option Strict On.
• Missing option explicit. Leaving this option undeclared allows the developer to use undeclared variables in the source code. Undeclared variables default to type Variant, which can hold a value of any type. Such variables result in the same upgrade problems as mentioned in the preceding bullet: the upgrade wizard cannot determine the correct property to use when your code uses the default property of an object declared as Variant.
• Soft binding of Form or Control. Variables declared as Form or Control can cause problems when upgrading. In Visual Basic 6.0, these generic classes can be used with properties and methods that are defined for particular forms and controls. Form and Control variables are supported in Visual Basic .NET, but accessing properties that are specific to a particular type of form or control is not supported.
• Soft binding using ActiveForm and ActiveControl. This usage pattern has the same upgrade problems as stated in the preceding bullet.

What should I do about the components of code fragments that are no longer used in the application to be upgraded?

For clarity and manageability, components or code fragments that are no longer used in the application should be removed. From the upgrade point of view, it is also important to remove unnecessary application elements before starting the process. This reduces the upgrade issues that will be generated after the automated upgrade and also decreases the quantity of code that needs to be upgraded. The assessment tool can be used to identify unused components.

Why should I have a resource inventory of the application to be upgraded?

The initial source code inventory made with the assessment tool is essential for the upgrade effort estimation. When upgrading earlier versions of applications, it is also important to have an inventory of resources such as documentation, design diagrams, test cases, and specifications. These resources are helpful in the final stages of the upgrade procedure, because the original test cases are the basis for testing the upgraded application.

How can I verify that the source code is syntactically correct?

The correct syntaxes of the source code can be verified by compiling the original application before the execution of the upgrade wizard. All compilation errors produced in the original application must be corrected to provide an appropriate input to the upgrade wizard. The compilation of the original application is also useful to verify that all the components and user-defined source code referenced by the application are available in the system.

In upgrading an application, what does ‘dependency’ mean?

When one application component uses another component, the first component is said to be dependant on the second. There are different types of usage that require different ways to identify such dependencies. Usage can appear in the form of access to a class member, invocation of a method, declaration of a variable with a particular type or the inclusion of an embedded control.

The knowledge about the dependencies between components and projects is essential for the upgrade engineer, since this information will be used in conjunction with other key considerations -such as strategic priorities, business value and available resources- to focus the upgrade efforts and maximize the results obtained.

What is the purpose of performing a partial test upgrade of the application?

As part of the preparation stage, it is important to perform a partial test upgrade of the application to determine or detect each of the following:

• Upgrade process speed. The time consumed by the upgrade of a part of the application can provide an idea of the time required to upgrade the entire application. This information is useful for the upgrade procedure planning.
• System resources. The available system resources, especially the amount of system memory, can be evaluated using a part of the application. The consumption of system resources is affected by the application complexity; if system resources show signs of excessive usage, such as extreme memory swapping (referred to as thrashing), the resources should be increased.
• Setup problems. Common setup problems, such as unavailable third-party components or out-of-date source code, can be detected in a partial test upgrade.
• Other common errors. Source code issues can be identified and corrected before the full upgrade of the application.

What are the most common automated upgrade issues and how can I solve them?

The following list presents the most common upgrade issues generated after running the upgrade wizard and how they can be solved after the automated upgrade has taken place:

• Property <object>.<property> was not upgraded. This warning is generated when a property cannot be automatically upgraded. To correct this problem, it is necessary to use a workaround that replaces the original functionality. It may require the reimplementation of certain application functionality.
• <objecttype> object <object> was not upgraded. This occurs when objects of unsupported classes are declared and used. Additional development work may be necessary to fix this problem.
• Use of Null/IsNull detected Null is not supported in Visual Basic .NET. Null is upgraded to System.DBNull.Value and IsNull is changed to IsDBNull. This value and function do not have the same behavior as in Visual Basic 6.0. Also, Null propagation is no longer supported in Visual Basic .NET. The application logic needs to be reviewed to change the usage of Null.
• <functionname> has a new behavior. Some functions have different behaviors in Visual Basic .NET. This requires a detailed review of the code to ensure that the application logic has not been altered.
• <object> event <variable>.<event> was not upgraded. Some events cannot be upgraded to Visual Basic .NET. The corresponding methods must be called if necessary.
• Could not resolve default property of object ‘<objectname>’. This is one of the most common issues you will encounter. It occurs whenever a late-bound variable is set to a value. This is the warning discussed in the previous code example.
• Could not load referenced component <reference>. This message is related to the setup of the application that is being upgraded. It will be included whenever a reference, such as an ActiveX control or class library, cannot be found. To correct this problem, verify that all necessary components are installed on the computer. This issue can be avoided by installing Visual Basic 6.0, with all referenced components, and ensuring the application compiles and runs before beginning the upgrade.

What steps should I execute to upgrade an application by using the Visual Basic Upgrade Wizard?

The following steps must be executed to upgrade the project:

1. Open Visual Studio .NET.

2. On the File menu, click Open, and then click Project. This displays the Open Project dialog box. Navigate to the location of the Visual Basic 6.0 project file, and then click the desired project file. For our example, navigate to the location in which you saved the SumApp project, click SumApp.vbp, and then click Open.

3. Read the welcome page, and then click Next.

4. On the Choose a project type page, the appropriate option is selected by default. Click Next.

5. On the Specify a Location for Your New Project page, the wizard suggests the target directory to be called projectname.NET, where projectname is your original project’s name. In our example, the suggested name is SumApp.NET. Click Next.

6. The Ready to Upgrade page of the wizard informs you that it is ready to perform the upgrade. Click Next to start the upgrade. The next page of the wizard displays information about the upgrade process status. A Status box shows the task the upgrade wizard is currently executing and a progress bar indicates an approximation of the time left for the task.

How do I run the upgraded application?

To run the upgraded application, press F5. The first time an upgraded project is built or run, you will be prompted to save the solution file. The .NET solution corresponds to the root of the tree displayed in Solution Explorer. A solution file is similar to a group file in Visual Basic 6.0. The upgraded project is contained in this solution file. Accept the suggested name for the solution, and then press Enter to save it. The project is then automatically built and executed. Form1 is displayed and waits for user input.

What happens when the upgrade tool is executed from the command line?

When the upgrade tool is executed from the command line, two processes are launched:

• VBUpgrade.exe. This is the front end of the tool for the command line mode.
• VBUD.exe. This is the upgrade engine.

The Windows Task Manager displays the two upgrade processes launched by the command-line version of the upgrade tool.

What are the main issues that might occur during the upgrade wizard execution?

In general, the upgrade process can be left unattended after all the required information is provided. However, large applications may take several hours; while it is upgrading, different situations that require user attention may arise.

The following list presents the most common issues that might occur:

Memory swapping. When the computer that is used for the upgrade of an application does not have sufficient memory resources for the processing of a large application, the operating system tries to provide additional memory to the upgrade process by swapping memory to disk. The swapping back and forth between memory and disk may consume more processing power than the other tasks. In this situation, the system is said to be in a “thrashing” state. In this state, the upgrade process can take a significant amount of additional time to finish. When this occurs, it is recommended that you stop the automated upgrade, increase the system memory, and begin the automated upgrade again.

Incorrect references. When an application has more than one project to be upgraded, you may choose to upgrade one project at a time. You can make some source code reorganization according to upgrade priority or other factors. If a reference to a user project or a third-party component is accidentally changed to another reference during this reorganization, the upgrade wizard will not be able to obtain all the necessary information about members and data types. This will generate warnings about default property extraction in all places where members of these components are used, because none of these members will be automatically upgraded by the upgrade wizard. If this happens, the corresponding reference and accesses to the elements contained in it will have to be reviewed.

Trial version of third-party components. The upgrade wizard loads all third-party components referenced in the project. Some trial version components display a license dialog box and wait for user input whenever the components is instantiated. This will cause the upgrade process to stop until the dialog box is closed. You should pay attention to these dialog boxes to allow the upgrade process to continue.

Upgrade wizard exceptions. It is an unusual scenario, but when a file is being processed by the upgrade wizard, it may be possible for the tool to encounter a fatal problem. For example, third-party components with a nonstandard interface or other conditions will produce an exception. In this case, the upgrade tool will terminate execution. The first step to solve this problem is to isolate the file and source code that is producing the exception. After this is done, the source code can be commented. After the problematic code is removed, the upgrade process can be started again.

What is the most common error reported by the upgrade wizard in typical Visual Basic 6.0 applications?

By far, the most common upgrade problem reported by the upgrade wizard in typical Visual Basic 6.0 applications is the default property extraction problem caused by lack of information about the data type of a variable. Depending on the usage of the variable, this problem can cause compilation or run-time errors. For information about other upgrade issues and the manual corrections you will have to apply to fix them, see Chapters 7 through 13.

What are the main issues that might appear in the upgrade report and how should I address them?

The following types of issues might be included in the upgrade report and will need to be addressed:

• Upgrade issues. These indicate unsupported class members or language elements. For each item identified, the functionality needs to be reviewed, and some of the affected expressions will require manual upgrade to similar .NET elements. Each upgrade should be tested in a limited scenario.
• Upgrade ToDos. These identify points in the source code that require user intervention. The instructions included in these items should be followed. Testing of the resultant code verifies that corrections were properly applied.
• Upgrade warnings. These items identify source code that will compile but may generate a run-time error. This code needs to be thoroughly tested to identify if and how run-time errors occur. Additional changes to prevent the occurrence of the run-time errors may be necessary.
• Design errors. These problems arise when unsupported design-time properties are used. Members whose behaviors have changed are also included here. The functionality that these members provide can be redesigned or changed by similar .NET elements. The code needs to be tested to determine whether the behavior differences have affected the core application functionality.
• Global warnings. Global issues such as the lack of deterministic object lifetime because of garbage collection are included here. Most of these warnings are caused by setup issues that can be easily fixed and tested. Other warnings require more work to be fixed, such as manual upgrade in the case of source code lines that are not recognized by the upgrade wizard.
• Upgrade notes. These are generated when the source code has been significantly altered or the resultant code has some behavior differences from the original Visual Basic 6.0 version. The code needs to be tested to determine whether the behavior differences have affected the core application functionality.

What do I do about run-time errors?

A high percentage of potential run-time errors are detected by the upgrade wizard. However, there may be problems that will be detected only after the upgraded application runs and is thoroughly tested, and need to be manually corrected. The original application test cases and design documentation is particularly important to identify such errors.

What are the most common upgrade issues that produce run-time errors?

• Changes to User-Defined Types. User-defined types can be defined in Visual Basic 6.0 using the Type keyword. All the members included in a Type block are automatically initialized by the Visual Basic 6.0 runtime.
• Changes to Null and IsNull. Null and IsNull have different behaviors in Visual Basic .NET than in Visual Basic 6.0. The upgrade wizard detects the usage of Null and IsNull. Null is upgraded to the closest value available in Visual Basic .NET, which is System.DBNull.Value. However, Visual Basic .NET does not support propagating the Null value. This will result in behavior differences that produce run-time errors.
• Changes to Array Indexing. In Visual Basic 6.0, it is possible to create arrays whose lower index bound is a value other than 0. In Visual Basic .NET, all arrays must have a lower index bound of 0. The upgrade wizard ensures all arrays have a lower bound of 0. However, if the source code relies on the calculated size of arrays, the behavior of the array code in the upgraded version will likely have different behavior than the original code.
• Changes to the Activate Event. It is not uncommon to include code to recalculate or refresh the state of a Form in the Visual Basic 6.0 Activate event. In Visual Basic 6.0, this event is raised only when switching between forms in the application. In Visual Basic .NET, the equivalent Activated event is raised in these situations, but it is also raised when switching from other applications. This will produce run-time differences between the two versions.
• Changes to ComboBox Control Events. In Visual Basic 6.0, the ComboBox control has a Change event that is raised when the user writes text into the control. In Visual Basic .NET, the corresponding event, TextChanged, is raised in the same situation. However, this event is also raised when the corresponding form is initialized, before it is even displayed. This may cause errors at run time because the TextChanged event will be raised form loads and the ComboBox has not yet been initialized.