VB.NET

Digg This!

Page 2 of 3   « previous page   next page »

If the VB6 program has variable names that match keywords in VB.NET, they'll be converted with '_renamed' appended to the declaration. The wizard doesn't always find where the variable is used, so the best option is to change the variable name before the conversion.

Don't bother with formatting code in the pre-conversion stage - the converter will do its own formatting during the conversion.

Well-Written Code Converts Well
I was around when Borland and then Microsoft released C++ compilers, and I was responsible for converting a lot of C code to C++. One lesson I learned was that well-written code converted far easier than poorly written code. So, the first task of a conversion effort should to clean up and simplify the original code. The following checklist contains some of the pre-conversion steps that will make the conversion easier - I will be covering all of these.

1. Declare all variables.
2. Give all variables explicit type, not variants.
3. Do not worry about code formatting.
4. Do not use 0 to disable timer, set enable = false instead (vb6 default is 0, enabled).
5. Can't be perfect (bring to front).
6. Do an internal test and release of a clean VB version before the final conversion.
7. Declare only one variable per line.
8. Remove dead code.
9. Set the startup object to a form.
10. Make sure the code compile. and runs before the conversion.
11. Convert all arrays to 0 based.
12. Remove all "as any."
13. Convert VB1 - VB5 to VB6 first.
14. Convert DAO and RDO to ADO.
15. Do not use defaults when accessing control properties.
16. Rename any VB.NET keywords in the VB6 code.

When I was doing the C to C++ conversions, one key quality indicator that I looked for was function prototypes. In C, prototypes were optional (and didn't even exist in the early days of C!). In C++, prototypes are mandatory. When I saw C code with prototypes, the conversion typically went well; when they were missing, other issues often came up during the conversion.

A similar quality indicator in VB6 is the declaration of variables and variable types. VB6 allows untyped variables in the form of variants. Actually, VB6 doesn't even require variables to be declared. In most cases, using variants is a bad programming practice; not declaring variables is always a bad programming practice.

So, the first thing to do when converting VB6 code to VB.NET is to add the Option Explicit to all code files, ensuring that all variables are declared. Next, specify all variable types, eliminating all variants that really only hold a single type. In many cases, it's obvious what type a variable should be, but incorrectly changing a variant that should be an Integer, Long, Single, or Double to a different type can cause bugs that are difficult both to detect and troubleshoot. This is one reason why I recommend a complete testing cycle after preparing VB6 code for conversion, but before doing the final conversion. If you can add more tests for corner cases in any math routines to your test suite, it would probably be worth it.

Another good practice is to declare one variable per line. Dim a, b, c As Integer creates two Variants and one Integer, not the three Integers you might expect. This error is more likely to cause problems in VB.NET than in VB6.

If your code is in an earlier version of VB, convert it to VB6 first. Next, if you use DAO or RDO to access databases, rewrite it to use ADO (more on this in the next article). VB.NET 2003 does a better job of converting VB than the original VB.NET, so if you're going to convert to .NET, it makes sense to skip VB.NET 2002 and convert straight to VB.NET 2003. Because of this, I won't cover converting VB.NET 2002, but most of the information given here will still apply if you choose that route.

After the upgrade, the new .NET project will be in its own folder, with the original VB6 project unchanged, so you can do as many trial runs as you like, and use the upgrade reports as guides to issues to correct before doing the final conversion. The update report is an html file listing files and the errors in each file.

VB6 and ActiveX Controls
Most of the basic VB6 controls will be upgraded by the wizard without any issues, as will many advanced and third-party controls. Even complex ActiveX controls like the MSChart and third party controls are likely to convert with only minor changes in syntax. For instance, the MSChart control converts and mostly behaves like the original. The biggest difference is that the Axis is accessed as a property in VB6, but this is done by using an accessor in VB.NET. For example, in VB6 the XAxis maximum value is set by the statement:

MSChart1.Plot.Axis(VtChAxisIdY,0).ValueScale.Maximum = 370

In VB.NET, it is set by the statement:

MSChart1.Plot.get_Axis(VtChAxisIdY,0).ValueScale.Maximum = 370;

As far as I can tell, this is the only property of MSChart that is treated with this minor difference. The wizard will automatically create a wrapper for any ActiveX controls used in the project. You can also create a wrapper for any ActiveX control you want to use in a .NET program by simply right-clicking on the toolbox, selecting add/remove items, and then choosing the ActiveX control from the COM tab of the Dialog Box. This task can also be accomplished by running the TlbImp.exe utility that comes with the free .NET SDK. One small difference: an "upgraded" ActiveX control is referred to by its original name when referenced in the program, but an ActiveX control added to a new .NET project gets an "ax" prefix. For instance, when upgraded from a VB6 project, MSChart stays MSChart; when added to a .NET project, it becomes axMSChart.

While complex components and ActiveX controls are moved to .NET via the use of wrappers, basic VB6 controls are upgraded to (replaced by) VB.NET controls.

Page 2 of 3   « previous page   next page »