If you're one of the many who have VB6 code, you have three basic options: stay with VB6, convert to .NET, or rewrite from scratch. In this article, we will look at converting VB6 code to VB.NET and C#. I'll discuss when it makes sense to convert versus staying with VB6 or rewriting from scratch. I will cover what converts well and what does not, different ways to do the conversion, how to get code ready to convert, and handling issues after the conversion.

Executive Overview
First, let's get an executive-level overview of where VB6 and VB.NET are at in their life cycles. Note that when I mention VB.NET in this article, I mean all three versions (2002, 2003, 2005). When I talk about a specific version, I will specify the version (such as VB.NET 2002). With the advances in VB.NET 2003, as well as its compatibility with VB.NET 2002, there is little reason to migrate to, or stay with, VB.NET 2002. VB.NET 2005 is still an unstable beta, so the focus here will be on converting to VB.NET 2003.

For those of you who wish to stay with VB6, the key fact is that VB6 developer licenses are perpetual, so developers who have licenses can continue to develop in VB6 for as long as they wish. However, VB6 was released in January 1999 and is approaching six years of age. As a result, it is near the end of its life (VB 1.0 was originally released in 1990). VB6 no longer exists as a stand-alone product - mainstream support ends in about six months - and all support will end three years after that. Currently, to get a new VB6 license, you must either buy VB.NET and then request a VB6 downgrade disk (for about $20), or get an MSDN subscription and download it from the archives. However, I wouldn't be surprised to see these dates extended.

VB6 can be a viable option for small- to medium-sized programs with limited lifespans, for several years to come. But for large, long-term projects that will need to be maintained for a number of years, VB6 is rapidly becoming a non-option.

VB.NET was in widespread beta, with some commercial applications shipping in 2001. Release 1.0 came in 2002 and version 1.1 showed up in 2003. VB.NET is clearly ready for primetime. As a bonus, Mainsoft Corp., Mono, and Portable.NET are preparing to take VB.NET code cross-platform.

VB.NET can be cheap; many VB6 developers are MSDN members and already have access to VB.NET. The stand-alone VB.NET product is about $110, and adventuresome folk can download a free copy of VB.NET 2005 that contains the upgrade wizard at lab.msdn.microsoft.com/vs2005/get/default.aspx. A DVD (or CD) of the VS2005 Enterprise version beta can be ordered for a shipping and handling fee from the same Web page. Serious developers and corporations will typically have one of the more expensive MSDN subscriptions and access to all of this and more.

Options
If you have VB6 code, your main choices are to stay with VB6, convert the code to VB.NET or C#, or rewrite the code from scratch in VB.NET, C#, or Java. If you plan to rewrite in Java, you are probably reading the wrong article (and probably the wrong magazine; may I suggest our fine sister publication JDJ).

Whether or not to convert a program is always a case-by-case decision, driven by several competing factors such as the quality of the original code, cost, programmer availability, customer base, etc. On one hand, the only clear case where not going through at least a trial conversion would make sense is if the product is at the end of its life, with only bug fixes being implemented, and no plans for future versions. On the other hand, few large VB6 programs will convert to VB.NET without some significant rewriting. In almost all cases, I think going through at least a quick "probe" conversion is a good exercise for almost all projects - even if the converted code is not used, some valuable lessons will be learned.

Although the focus of this article will be on VB6 to VB.NET conversions, those of you moving to C# or looking at a complete VB.NET rewrite can still benefit from a conversion to VB.NET. For those of you looking at moving to C#, there are several tools (we will take a quick look at a couple of them later) that convert VB.NET to C# (and back), so it makes sense to convert to VB.NET as a step on the way to C#. If you're planning to do a complete rewrite to either VB.NET or C#, you can use the VB.NET conversion wizard to get a head start. In most programs, there are blocks of code that implement algorithms or business logic. These blocks of converted code can be pasted into a new project, speeding development for those choosing to do a complete rewrite.

Also consider that there are different levels and methods of conversion. If you have an ActiveX control written in VB6, a true conversion would be to rewrite it as a WinForm control in VB.NET. A better option might be to wrap the control in a .NET wrapper and use it from .NET while converting and testing. Shipping a VB6 ActiveX control with a .NET application can complicate the install because the VB runtime and associated files must also be installed. This is the same installation that is required if the control is installed with a VB6 application, but it is obviously more complex than the simple XCopy install of pure .NET applications.

Another way in which this ActiveX wrapper trick can be used is on forms that do not convert well, regardless of the reason. If the form can be moved to a separate project that was created as an ActiveX control project, the resulting ActiveX control can be added to a replacement form in VB6 or to a VB.NET project. Any form that can be separated from the rest of the program in this manner can be converted to an ActiveX control and used from .NET using .NET's built-in interop capabilities. In addition, we will see that most simple DLLs can be easily used directly from .NET.

In converting from VB6 to VB.NET 2003, three areas will be looked at: general VB6 code, ADO database code, and ASP Web page code. In this article, I concentrate on using the upgrade wizard to convert general VB code to VB.NET. In the future articles, I will finish general conversion issues, covering ADO, ASP, C#, and VB.NET 2005.

Before We Even Start
Remove dead code; you cannot have trouble with code you do not convert. Remove variables that are never used and subroutines that are never called. I converted one application that was large enough to have a number of associated programs, such as configuration programs, format converters, upgrade tools, and some ActiveX controls. Most of these utilities shared header files (WIN32 API declare statements and user type definitions) with the main application, but most of these programs only used a few of the functions in the headers. Other applications did not use anything in some of the headers. By removing the unused files and functions from the project, I was able to convert all the utilities much quicker. This allowed some functionality to be shown quickly, and provided the experience needed to tackle the main application.