Before You Migrate

Two important questions must be asked and answered when it comes to migrations from VB6 to VB .NET: "Should I migrate my application to VB .NET?" and "If I do choose to migrate, what is the best practical way for me to do it?" The first question should be asked for every single application. The answers to these questions result in different desirable outcomes .

To Migrate or Not to Migrate

Before you we talk about how to migrate, let's talk about whether to migrate. If I had a VB6 application that worked fine and required no additional significant features, most likely I would not migrate it at all. However, if I did elect to migrate such applications, I would place this category way down on the priority list. Microsoft has not abandoned VB6 (the company hasn't even abandoned COM), so why migrate a perfectly good program? There is no reason to.

Unless some bizarre catastrophe occurs in the world, Microsoft will offer plenty of lead time ”probably years ”before VB6 is cast to the wayside.

So You Want to Migrate

Now you are telling me, "But I have to migrate." Your application is undergoing significant revisions, a manager has made a sweeping decision ”say, for security's sake your company wants all managed code ”or for some other reason you are in a position where you must migrate. If you must migrate, you still have choices.

You do not have to migrate your entire application. You have a couple of options here. First, of course, you can run the migration wizard, updating VB6 to VB .NET and manually fixing all the code that could not be automatically migrated . This is a valid option, and we will talk more about it in a moment. Second, you have the option of importing your VB6 libraries with COM Interop, leaving you to reproduce the presentation layer (graphical user interface) in VB .NET. Using COM Interop (see Chapter 7) is a great alternative to a complete migration. A third option is to implement application bridges using XML Web Services or .NET Remoting. This option should work very well, especially for VB6 applications that have OLE Automation interfaces. The fourth option, which is technologically sound but may be cost prohibitive, is to completely rewrite your VB6 applications in VB .NET, and there are compelling reasons to do so. (I offer the examples of what you can do with VB .NET, as described in this book, as my argument for a rewrite.)

Migrating just to learn VB .NET is not a good idea. The migration wizard produces verbose code that will not teach good object-oriented programming principles, nor will the migration wizard produce ideal object-oriented code. What the migration wizard will do is as much as necessary to allow your migrated code to compile, and it is highly unlikely that any but the most trivial applications will migrate completely and automatically.

If you are sitting on the fence and can't decide whether or not to migrate, you may want to run the migration wizard and examine the migration report. The report should tell you how much effort will be involved in migrating your VB6 applications, which you can in turn use to help you weigh the alternatives. (Refer to the upcoming section Migrating Visual Basic 6 Windows Applications for more details.)