The need for a support library

When we demo VB Migration Partner to prospecting customers, one of the most frequent questions that come up is: Why does it require a runtime support library? It’s such a reasonable question, in fact, and deserves a detailed answer.

One of the first things that hit me when testing the Upgrade Wizard in Visual Studio is the abundance of the migration warnings it emits with even the simplest VB6 projects. Most of these warnings are basically like this: “This keyword/property/feature behaves differently in VB6 and VB.NET: read this help page for more information.” Alas, in many cases the help page is either missing or too generic. And if the page is not missing and is enough exhaustive, understanding it often requires an in-depth knowledge of the many subtleties of the .NET Framework. How can you explain all the nitty-gritty details of object finalization, GDI+, or drag-and-drop in one short page –to mention only three of the areas where VB6 and VB.NET differ in a significant manner?

When we began working on our own conversion tool, we were determined to dramatically cut out both the sheer number of migration warnings and the time an “average” developer would spend to fix each of them. Our reasoning is simple: if you are using our tool, chances are that you aren’t very familiar yet with VB.NET. Do you really want to set apart the actual migration job and study .NET each and every time you try to migrate a VB6 statement that doesn’t exactly behave as in VB6? Wouldn’t you prefer to have a wrapper method that hides all these differences and guarantees that the new program behaves like the old one?

The Format method is implemented very differently in the two languages, thus it provides a good example of the concept I am illustrating. The VB.NET version support neither named formats (e.g. “percent”) nor string alignments, and uses different placeholders for most values (e.g. “tt” instead of “AMPM”). As a matter of fact, you can rarely migrate a statement that uses the Format method without adjusting the pattern string. If the original VB6 application contains 100 calls to the Format method, you’ll probably spend a couple of hours just to fix the string patterns and test the result. Often even more than a few hours, because many of the differences between the two languages aren’t documented at all, therefore you have to learn them the hard way. To be honest, it took us a few days to discover all these tiny differences. Well, do you like wasting this time yourself or do you prefer using our Format6 replacement method?

But the support library does more than just providing a one-to-one substitution for language keywords and methods. For example, the way you implement the drag-and-drop feature under VB6 – either the manual and the automatic mode, as set by the OLEDragMode and OLEDropMode properties – is completely different from the way this feature works under VB.NET: member names and arguments are different, and even the sequence in which events fire is different. A developer might need hours to manually translate every single form that contains drag-and-drop code, not counting the time required to learn how drag-and-drop works under .NET in the first place.

A support library has other advantages, too. Let’s suppose that Microsoft releases a new version of Internet Explorer that makes the WebBrowser control behave slightly differently than it does today, for example it reverses the order in which the DocumentComplete and the NavigationComplete2 events fire. It could easily be a serious problem, because you have massively used the WebBrowser control in your VB6 projects and consequently in your migrated VB.NET applications.

What you do next depends on how you’ve migrated the VB6 application. If you have used a “classic” conversion tool you now need to re-test all your apps: if the change in IE does affect your code you must come up with a fix, recompile the source code, and redeploy the new executables to your customers. On the other hand, if you’ve used VB Migration Partner, you just need to download the new version of the support library and send it to your customers. Fast and clean! Basically, you are moving part of your maintenance costs to us. Can you ask for more?