Fixing Problems with the Upgrade Wizard Execution

This section includes some common problems that may arise when running the upgrade wizard. 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. Figure 5.l6 illustrates a system that is upgrading a huge application and is in a thrashing state. Notice that all the processor time is consumed by the kernel and almost all the memory is used.

Figure 5.6

The Windows Task Manager Performance display in a typical "thrashing" scenario

Figure 5.6

The Windows Task Manager Performance display in a typical "thrashing" scenario

• 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. You may want to report these types of exceptions to newsgroups so that other developers can avoid them. Some suggested newsgroups are microsoft.public.dotnet.languages.vb.upgrade and microsoft.public.dotnet.languages.visualbasic.migration.

Being aware of and planning ahead for known exceptions can help you to have a smoother upgrade.

0 0

Post a comment