Working with EWIs

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.

Recommended Steps to fix a Migration Issue

This section shows the recommended steps to fix an error related to both EWIs and other migration errors: These are:

Locale the source of the problem

The fix step to fix an error is to locate the specific line or section of source code that is causing the problem. For a Compiler Error is very simple because the Visual Studio compiler will show you the line of code directly. For a Runtime Error, however, this task has additional complexity.

A good process for finding these is to:

  • Add a breakpoint in the .NET application a few lines before the code where the exception or the different behavior manifests itself
  • Add a breakpoint in the VB6 application in the corresponding line where the .NET breakpoint was add in the step 1
  • Run both applications until you hit the breakpoint. The, debug step by step both the VB6 application and the .NET application and the same time. With this approach, you can quickly determine differences between the values of the variables involved in the process and on the execution flow, which would point out the differences between the two applications that may be causing the problem.
  • If the is no difference between the values and the execution flow, the next step is to move the breakpoint several lines back. This may require adding a breakpoint to other methods in both applications the VB6 and the .NET applications.
  • If a difference in the value of a variable is found you can do a search to find out other places where this variable has a value assigned to determine where it is getting a different value.

Understand the code purpose in the original VB6 application

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

  • Read the VB6 documentation for the line of code that is failing. For example, if the problem is related to drag and drop, it is important to understand in detail how this feature works.
  • Create small examples of code that use the same features.
  • Execute again step by step (debug mode) the section of the code causing the problem.
  • If possible, ask to the developer who maintains the application.

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 migrated .NET application. Some recommendations for this are:

  • Review the related.NET documentation on MSDN to determine how to archive the same functionality in .NET. Going back to the “drag and drop” feature, it is important to understand in detail how it is used in.NET and what are the differences with the VB6.0.
  • If available, review any the historical data on migration problems to find solutions implement by other consultants.
  • Perform a general search in the Internet using a regular search engine
  • Create small examples of code in .NET to replicate the VB6 functionality.
  • Ask your peers or a migration expert.

Implement the solution

The following process should work as a guideline to actually fix the code in .NET with the solution identified in the previous step. It consists of the following activities:

  • Modify the code of the migrated application with the identified solution
  • Test the migrated application to confirm that the behavior is the same than the original VB6 application.
  • Review the rest of the migrated code to determine in the same problem is present. If the error is present in other areas then a Customization Opportunity can be considered. Several factors must be taken into account at this point:
    • Timing: Will the current timeframe of the project allow the Artinsoft Product Team to implement the required customization? If not, is the impact of the error large enough to justify it to be reported in order to be included in future releases and 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 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:

  • Description of the problem
  • Description of the solution
  • Examples of the problem and the solution in VB6 and .NET respectively.
Skip Navigation Links.