The number of generated EWIs depends entirely on your programming style and the size and type of files that make up migrated application. As a rule of thumb, forms usually have more issues than classes and modules. This is caused because forms have a richer object model and significant transformations must be applied when performing the upgrade to Windows Forms.
The best approach to dealing with EWIS is to get the application to compile and run as quickly as possible, leaving the runtime differences, non-critical work, and improvements until later. This requires fixing compilation errors and ToDo EWIs first.
A way to make this work is to use Visual Studio’s Task List. You can filter the Task List to show all the EWIs and compilation errors or to show only the compilation errors. Start by filtering by compilation errors only. Once the project is running, you can start applying fixing runtime errors related to EWIs.
For each EWI, it is better that once a problem is fixed, have the EWI in the code to prevent it for showing up in the Task List. This ensures that the Task List shows an accurate list of remaining issues.
This section shows the recommended steps to fix an error related to both EWIs and other migration errors:
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, that way you can compare to know what is causing the problem or why the problem is occurring.
The next step is to understand, in the original VB6 application, the actual functionality of the section of the code causing the problem. You can perform the following activities to understand the original behavior:
Once the functionality of the original VB6 application is understood, the next step is to replicate the same functionality in the migrated .NET application. Some recommendations for this are
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 a Mobilize.NET Customization. Several factors must be taken into account at this point:
Once the problem is resolved, it is important that the solution is properly documented and stored in a shared knowledge base so other developers that run into this issue are able to access it. This documentation should include the following information:
8834 N Capital of Texas Hwy, Ste 302
Austin, TX 78759
Call us: +1 (425) 609-8458
info@wearegap.com