Because migrating a really trivial application would be misleading and a really long application would easily consume dozens, perhaps hundreds, of pages, I picked a sample application to migrate. The application consists of a separate client and server and is available with MSDN. (You will need to have MSDN for Visual Studio 6 installed, or you can acquire a copy of the source code from Microsoft to repeat the steps described here.)
Table A.1. VB6 Features Unsupported in VB .NET
The two programs that comprise the application I elected to migrate were in my Visual Studio files in C:\Program Files\Microsoft Visual Studio\MSDN98\98VSa\1033\SAMPLES\VB98\misc\booksale\Client\BOOK_CLI.VBP and C:\Program Files\Microsoft Visual Studio\MSDN98\98VSa\1033\SAMPLES\VB98\misc\booksale\Server\BOOK _SVR.VBP . (These paths might vary depending on the exact version of MSDN you have installed. Search on the project names to find the files if necessary.) This is a modestly complex client and server application. The application contains many of the most common elements, including forms, classes, and modules. I will provide an overview of the process and some of the problems that have to be reconciled, but I will not provide the listing since it would require too many pages.
Migrating the Sample Client Application
If you select FileOpenProject and select a VB6 project (a .vbp ) file, the migration wizard will start automatically. I used all the default options in each of the five steps, and this part of the process is trivial. Figures A.1 through A.5 show you when you are in the right place and help you retrace my steps if you are so inclined.
Figure A.1. This is the first step of the migration wizard, which you should see if you attempt to open a VB6 project.
Figure A.5. The migration may take a few minutes, as suggested by the progress bar.
Figure A.2. This is the first step of the migration wizard, which you should see if you attempt to open a VB6 project.
Figure A.3. Navigate to the .vbp project you want to migrate.
Figure A.4. The wizard begins the migration after you click Next on this screen.
When you are finished migrating, you should see an entire VB .NET solution ( .sln file) with all the migrated files, references to COM Interop assemblies, and a file named _UpgradeReport.htm . The upgrade report is a good place to start. The _UpgradeReport.htm file (Figure A.6) provides you with a list of migrated files. Expand the list (Figure A.7) to see specific problems with a hyperlink description. Click on the linked description to navigate to a specific help topic that will explain what the problem is and recommend a resolution.
Figure A.6. The _UpgradeReport.htm file is the place to start after finishing the migration wizard.
Figure A.7. Expand migrated files in the _UpgradeReport.htm file to navigate to the help link that documents the migration error and resolution.
A reasonable approach is to resolve all the items in the task list and get the code to compile. Then you will need to retest the application for logic errors. For example, calls to IsObject with a variant in VB6 are migrated to IsObject with an Object type in VB .NET, and the results are evaluated differently. Carefully retest your entire application.
Resolving Migration Errors
When I ran the migration wizard I had only four bonafide compile errors. Everything else was a warning. After fixing the errors and compiling I addressed the warnings to determine whether they were really errors waiting to happen and to figure out what could be done to resolve them. Professionally, I have a rule: I don't ship code with errors, warnings, or hints. Everything gets resolved 100 percent, one way or another.
To view compiler errors and resolve those first, select ViewShow TasksBuild Errors. This filters the task list to show you everything that is preventing your application from compiling.
The first error I tackled was " frmCogs is a type and cannot be used as an expression." By examining frmCogs we can determine that frmCogs has been migrated to a WinForms object; hence we must know how to rewrite this code in VB .NET. Listing A.1 contains the method in question, and Listing A.2 contains the revised code, which resolves the error.
Listing A.1 An Improper Way to Load a Windows Form
Private Sub cmdCogs_Click(ByVal eventSender As System.Object, _ ByVal eventArgs As System.EventArgs) Handles cmdCogs.Click goStatusPanel.Text = "Determining Cost of Goods." 'UPGRADE_ISSUE: Load statement is not supported. Click for more: 'ms-help://MS.VSCC/commoner/redir/redirect.htm?keyword="vbup1039"' Load(frmCogs) goStatusPanel.Text = "" End Sub
Clicking on the hyperlink in the _UpgradeReport.htm file takes you to the VS .NET help topic ms-help://MS.VSCC/MS.MSDNVS/vbcon/html/vbup1039.htm . This help topic shows you VB6 code, what the VB .NET migrated code should look like, and a remedy. The problem I encountered , in short, is that the Load method isn't used to load forms in VB .NET. Forms are classes, and we use the new operator and invoke methods on forms just like any other class. Listing A.2 shows a revision that is correct and resolves the error.
Listing A.2 Fixing the Load Error
Private Sub cmdCogs_Click(ByVal eventSender As System.Object, _ ByVal eventArgs As System.EventArgs) Handles cmdCogs.Click goStatusPanel.Text = "Determining Cost of Goods." 'UPGRADE_ISSUE: Load statement is not supported. Click for more: 'ms-help://MS.VSCC/commoner/redir/redirect.htm?keyword="vbup1039"' Dim form As frmCogs = New frmCogs() goStatusPanel.Text = "" End Sub
Typically in .NET we create a form with the New operator and then call Form.Show or Form.ShowDialog . The migrated code actually contains the call to Show in the Load method, so we didn't need to do it here.
There was one more error like this plus two errors related to a mouse click event. In all, migrating BOOK_CLI.VBP took about five minutes, and resolving the basic errors took another five minutes. Thus after ten minutes the client application compiled and ran. In addition, because in VB .NET we can talk to VB6 servers, I was able to run both the client and the server by converting only the client. Figures A.8 and A.9 show the client and server running, respectively.
Figure A.8. The migrated client application running as a VB .NET assembly.
Figure A.9. The server application running as a VB6 executable, interacting with the .NET migrated client.
At this juncture we still clearly need to evaluate all the UPGRADE_ISSUE task items and resolve those. However, we have a choice, relative to the server. If the server is running, we can evaluate it as a separate application and decide whether or not to migrate it. It all depends on your needs, budget, time constraints, and priorities.
The number and variety of potential errors are too great to provide a comprehensive list of problems and resolutions . The best approach is to really understand the .NET Framework and in the meantime rely on the _UpgradeReport.htm file and the help documentation. Microsoft claims that the migration wizard will migrate about 95 percent of VB6 code, which should put you in pretty good shape.