EWIs

The following section provides useful information about the messages (comments) that will appear on your upgraded code and how to solve them.

Working with EWIs

The number of EWIs in your code depends entirely on your programming style and the size, type and complexity of files that you want to upgrade. As a general rule, forms usually have more issues than classes and modules, because forms have a richer object model and significant transformations must be applied when upgrading to Windows Forms.

Steps to fix a migration issue

This section shows the recommended steps to fix an error related to EWIs. The steps are:

Locate the source of the problem

To find the source of the problem, you can add some breakpoints a few lines before the code where the exception or the different behavior manifests itself. You need to do this in both the original VB6 code and the upgraded code so that you can compare to find out what is causing the problem or why the problem is occurring.

Understand the code purpose in the original VB6 application

The next step is to understand, in the original VB6 application, the functionality of the section of the code causing the problem. You can perform the following activities to understand the original behavior:

Create small examples of code that use the same features.
Execute step by step (debug mode), as many times as you need, the section of code causing the problem.

Identify a solution in .NET

Once the functionality of the original VB6 application is understood, the next step is to replicate the same functionality in the upgraded .NET application. Some recommendations for this are:

Create small examples in .NET to replicate the VB6 functionality.
Review the related .NET documentation on the web to determine how to achieve the same functionality in .NET.
Ask your peers or a Mobilize.NET migration expert.

Implement the solution

If you already have a solution, you can implement it. Once you have modified the upgraded code and the found solution was implemented, you need to test your code to confirm that the behavior is the same as the original VB6 application. You can, also, review the rest of the upgraded code to determine if the same problem is present in other areas.

Mobilize.NET Customization (optional)

In some cases, you can consider Mobilize.NET Customization. Several factors must be taken into account at this point:

Timing
- Will the current timeframe of the project allows the Mobilize Team to implement the required customization? Is the impact of the error large enough to justify it to be reported in order to be included in future releases used in future projects?
Complexity
- Is there an opportunity to make the replacement in several places using another automated solution such as Regular Expressions?
Rework required
- Are the manual changes performed at this point in the project so many that executing a code merge will imply too much additional work?

Document the solution

Once the solution is implemented and the problem is resolved, it is important that the solution is properly documented and stored in a shared knowledge base. This helps in cases where other developers run into the same issue and are able to access information on how to solve it.