Working with EWIs

Working with EWIs

Now that we ve discussed the types of EWI that will be generated during upgrade, let s look at how to use EWIs to get your project working. At this point, you might have a few questions: How many issues should I expect to see in my upgraded project? How do I know when I ve made the right fix? How do I keep track of what is left to fix?

The number of issues depends entirely on your programming style and the size of the project items. If you ve followed all the recommendations in Chapter 4 you might minimize the number of EWIs to fewer than 10, or perhaps 0, per file. As a rule of thumb, forms usually have more issues than classes and modules, since forms have a rich object model and must be changed significantly when upgraded to Windows Forms.

The best idea is to get your project running as quickly as possible, leaving the run-time differences, noncritical work, and improvements until later. Fix the compile errors and ToDo items first. That way you ll be working with a project that is runnable as quickly as possible. You can filter the Task List to show all the EWIs and compile errors or to show only the compile errors. Start by filtering the Task List to show only compile errors. For information on filtering the Task List, see Chapter 6.

A good method for working with EWIs is to fix a problem and then remove the EWI in the code so it stops showing up in the Task List. This ensures that the Task List shows only the issues left to resolve. Some compile errors can also be postponed. Your application might have code that performs a noncritical function, such as drawing a picture onto a PictureBox. You could decide to comment this out and add a remark such as the following:

'TODO: Fix Paint Code later

These ToDo comments will show up in the Task List when you change the filter to show all tasks. You can take care of noncritical functionality later, after you ve done the important work. The main advantage of getting the project into a runnable state as soon as possible is psychological: it s a satisfying feeling knowing that your project is basically working, even if you have a few modifications left to make.

How do you know which modification you need to make for each EWI? The Visual Basic .NET Help will assist you with this. In the beginning, the modifications might take quite some time to fix, since you re learning about upgrading and Visual Basic .NET at the same time. The good news is that after you ve fixed a problem the first time, you ll find that fixing the same problem again is much quicker, since you know what you re doing.

Performing a Two-Pass Upgrade

Open an old Visual Basic 6 project. Which EWIs do you think would be generated if you upgraded it to Visual Basic .NET? If only you had a way to know before upgrading! Perhaps you would change late-binding code or other easy-to-fix problems before upgrading. In these situations a two-pass upgrade is useful. The concept of a two-pass upgrade is simple: upgrade the project twice. The purpose of the first upgrade is simply to generate an upgrade report to identify where the problems are. You discard the first upgraded project after examining the report. Using the upgrade report, you fix some of the issues in Visual Basic 6 before upgrading a second time. The second pass is the real upgrade. When you do the second upgrade, you replace the first upgraded project, and you should have fewer issues to fix than in the first pass. In many cases, the two-pass approach significantly speeds upgrading.