I took the lead in porting a small (few thousand lines of code) VB6 application to VB.NET and here are some notes I made during the process, in case they're useful for anyone else.
There's a built-in upgrade tool for VB 6 to VB 2008, but it's not a one-to-one conversion. The process you'll need to follow goes like this:
- Run the VB 6 code through the converter, which will mark errors and sections that will fail to be upgraded.
- Rewrite those sections one by one and re-run the converter to see if they'll now convert easily. You should do this in small chunks, while re-compiling and running some simple tests if possible to make sure that your changes were logically equivalent to the original code and didn't break anything.
- Repeat the process until the reporter is showing a minimum number of errors that can't be resolved in VB 6. You'll have to tackle these yourself in .NET after the conversion has been done.
Pre-Pre Conversion Problem Areas
Lots of VB6 programmers didn't use strict type checking in their projects. You should go through each source code file and add two lines to the top:
Option Explicit Option Strict On
If you're using a CVS and don't want all the files touched, there are also command-line parameters for the compiler and project options you can use, but you'll have to search through the source files just to make sure they aren't set to OFF, as the source file options override project (and possibly compiler) options.
The kind of weird problems that this will show up in legacy code are:
- Section of code that have never been used.
- References which don't exist.
- Misspellings of variable names.
- Scoped variables that hid other variables.
- Called subroutines which don't exist.
Pre-Conversion Problem Areas
- The most common issue will be variables of type "Variant", which isn't supported any longer. You'll need to do some digging to find what data type the variable is actually used for, and use that explicitly instead.
- Arrays which use a non-zero lower bound will also cause problems. You'll have to change these to use 0, then scan all references in the code and decrement any indexes by the difference.
- Automatic conversion between compatible variable types will also be a problem. You should clean these up by using explicit casts (CInt, CStr, etc).
Post-Conversion Problem Areas
- Another big issue will be structures that have been treated as strings, or assigning one type of structure to another type of structure (this was common when using strings as a buffer to map between two similar structures). The only way I'm aware of handling this is with some convoluted inter-op code.
- You'll need to replace ON ERROR lines with try/catch exception handlers. This can get tricky when the original error handlers are shared between different portions of code.
You should now conduct some heavy testing to see if the program works before continuing.
Post-Post Conversion Problem Areas
- If the original application was a service, the NTSVC.OCX reference (and any code) can be removed, then you can create a new .NET native service project, and drag the converted application source files into it.
- Settings that used to be stored in configuration files and the registry can now be easily moved into XML configuration files.
- Variables which are in global storage can be moved into more logical objects.
Once that's all done, and tested, the final thing I would recommend, but has been hotly debated elsewhere, is disabling the VB 2008 Compatibility Layer (a Microsoft.VisualBasic in Reference). You can read about the functions it provides here: Visual Basic Run-Time Library Members.
What this will do (mostly) is flag all of the areas in the application that use "old-style" file and string handling, so that you can go through and replace them with .NET equivalents. Some say this takes away the Visual Basic from Visual Basic, but in my opinion it only takes away the bad/legacy bits. The best thing about VB is the simple syntax and avoidance of having to deal with classes straight away, and all of that still remains.