Migrating From VB6 to .NET
There is a ton of stuff/applications out there which have been written in VB6 and which are still around in many organisations. Previously when I was working with Java, I used to deride people who were writing in VB6 for reasons such as no object oriented paradigm and that it ran in a pseudo interpreted mode. It was however easy to create GUI applications on the Windows Operating System and allowed an easy method for linking to COM/DLLs.
As we’ve just recently migrated a business critical application for a client, I thought I would share some of our learning. Migration of an existing piece of code is never an easy task and even more so when there is no documentation provided with it and has been developed by a one man band outfit who is no longer interested in supporting it. We are talking the type of code that no self respecting .NET developer would want to touch in that state.
There are a number options for legacy VB6 applications, which are :
- Rewrite the application in .NET from scratch
- Migrate the application using the Visual Studio 2005 Migration Wizard
- Use the Interop Forms Toolkit to add .NET functionality running within a VB6 process for a gradual migration process
We used the Migration Wizard in Visual Studio 2005 which takes the VB6 code and attempts to automatically upgrade the project to VB.NET. After the upgrade has taken place you would attempt to compile the new project. The likelihood is that there will be many compile time errors which would have to be individually resolved. This is a painstaking process and certainly not glamorous.
VB6 and VB.NET only have the “VB” bit in common, they are essentially completely different programming languages. VB6 is unmanaged code and loosely typed, whereas VB.NET is managed code and strongly typed. Therefore at this stage significant portions of the application may require to be rewritten. Migrating to .NET is a good choice as this is a great platform to develop for and Visual Studio is still probably the best Development Environment around.
Once you have got a clean compilation and subsequently resolved any linking issues to DLLs/COM components you can then attempt to run it. This is the point at which you will hit the runtime errors and where you will discover that linking to some of your precompiled DLLs no longer work. This is also where you find that the User Interface looks rubbish because the Migration Wizard has converted into a Form Control which is not like the original. Also you must remember that there is not a one-to-one mapping between the VB6 Controls and VB.NET Controls, so you’ll probably be doing more rewriting here.
Microsoft has a good site for VB6 Resources and Migration Guides.
You can also find the support statements for VB6 here, which is essentially out of mainstream/extended support.