EWIs
The following section provides useful information about the messages (comments) that will appear on your upgraded code and how to solve them.
Last updated
Was this helpful?
The following section provides useful information about the messages (comments) that will appear on your upgraded code and how to solve them.
Last updated
Was this helpful?
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.
This section shows the recommended steps to fix an error related to EWIs. The steps are:
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.
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.
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.
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.
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?
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.
Below are a few of the most common warnings generated by the Visual Basic Upgrade Companion.
Code number
Description
206
1003
1044
1047
1049
1063
1068
2050
2065
2074
2077
2080
2081
2099
6002
6021
6022
7005
7006
7008
7009
8007
Below are a few of the most common issues generated by the Visual Basic Upgrade Companion.
Code number
Description
1002
1010
1014
1043
1046
2038
2064
2068
2070
7003
Below are a few of the most common ToDos generated by the Visual Basic Upgrade Companion.
Code number
Description
1035
1050
1059
1065
1067
1069
2018
2045
7010
7016
Below are a few of the most common Notes generated by the Visual Basic Upgrade Companion.
Code number
Description
6016