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.
The steps involved in an upgrade project can be divided in the following task groups:
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.
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.
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.
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.
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.
There are two main environment aspect types that 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.
Preparation for an upgrade process involves the following three areas that consider different aspects of the original application:
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.
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.
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.
The following list shows a sample of the predetermined rules that are detected by this tool:
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.
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.
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.
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.
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:
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:
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.
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.
When the upgrade tool is executed from the command line, two processes are launched:
The Windows Task Manager displays the two upgrade processes launched by the command-line version of the upgrade tool.
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.
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.
The following types of issues might be included in the upgrade report and will need to be addressed:
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.
8834 N Capital of Texas Hwy, Ste 302
Austin, TX 78759
Call us: +1 (425) 609-8458
info@wearegap.com
