[WHITEPAPER] Comparing VB Migration Partner with Upgrade Wizard

clock January 30, 2009 03:58

In the last year I have blogged a lot, ranging from short tips to complete articles on migration. Finding these articles isn't simple, unless you know what to look for, so we decides to republish this material in the form of self-consistent white papers.

Today's white paper is entitled Comparing VB Migration Partner with Upgrade Wizard, and comes from the merge of this and this post.

The title says it all. Enjoy!



Two sessions at Basta! Italia conference

clock January 26, 2009 02:32

I am giving a couple of migration-related sessions at upcoming Basta! Italia conference, on March 18th in Rome:

   Fun with Regular Expressions
   Tips, Traps, and Techniques in migrating VB6 apps to .NET

In the latter session I'll show many of the techniques we used to ensure that VB Migration Partner has such a high success rate, and will  also give a short demo of our software.



[COMMENT] A tool for serious migration jobs, at last

clock January 24, 2009 01:04

Just received from one of our customers:

In 2002 I was very excited to see that Visual Basic had become a true OOP and modern language, even if that meant breaking the compatibility with VB6. Alas, the excitement faded away quickly when I tried the Upgrade Wizard included in Visual Studio .NET: even the simplest projects required hours of manual labor just to compile without errors. And once compiled they often didn’t work as they were supposed to do, especially if they made calls to Windows API.

I eagerly waited for each subsequent Visual Studio .NET release, hoping that Upgrade Wizard had evolved from a toy into a tool capable to convert real-world business apps. Each time it was a disappointed and we had to postpone the migration of our document management system (counting over 500,000 lines of VB6 code spread in many different projects).

Then I tried out VB Migration Partner… at last I had control on the migration process, thanks to pragmas, regular expressions, and a support library that ensures a very high degree of compatibility with the original behavior. As it often happens, the simplest ideas are the most effective ones!

In my opinion, the main VB Migration Partner strengths are its extreme flexibility and the excellent tech support. The Code Architects Team always solved all our doubts and problems, often in a matter of hours. Francesco Balena in person replied to the toughest queries about COM marshaling and object disposal. It was a pleasant surprise to find such a competent team and a company that is willing to extend their support to issues that aren’t strictly related to their product.

Stefano Baldi
Engineering PLM Solutions
, Italy

Read more comments from our users.



[DOC] Differences between VB6 and .NET controls

clock January 23, 2009 05:30

In these three years we at Code Architects work very hard to study, discover, analyze, dissect, and devise workarounds for the huge set of differences between VB6 and VB.NET.

We put all this knowledge into our VB Migration Partner, of course. But we thought it was fair to make this information available to the many VB6 developers who still have one or more apps to convert, regardless of whether they would buy our software.

Yesterday we more than doubled the amount of material freely available on vbmigration.com, and in fact we decided to split this knowledge in two pages:

The control page currently lists the differences between VB6 built-in controls (forms, textboxes, labels, buttons, etc.) and their Windows Forms counterparts. We plan to cover the remaining controls - such Windows Common Controls, RichTextBox, etc. - in the near future. Stay tuned!


Welcome Infortech, our Japanese partner!

clock January 22, 2009 03:02

I am very excited to announce that we just closed an agreement with Infortech, a large and important Japanese vendor, with subsidiaries in China and Malaysia too.

Infortech is translating VB Migration Partner's documentation and will provide presale and tech support to our Japanese and Far East customers.

Added On Jan 23rd: the interest for VB6 migration in Japan must be really high, considering that several technical sites (this, this, this and this) have rethrown the news soon after the announcement. Wow!


A repository for users' feedback

clock January 21, 2009 03:35

Yesterday I spent some time putting together the most interesting comments from VB Migration Partner users and the .NET community...



VB Migration Partner vs. manual porting from VB6

clock January 20, 2009 02:31

More and more VB6 and VB.NET developers are discovering VB Migration Partner and are realizing that it *is* possible to convert VB6 legacy apps in a fraction of the time (and money) that is required when following other approaches or using other tools. However, a casual visit to VB6/VB.NET forums shows that many false myths and misconceptions about migration are still strong.

For this reason, every now and then I like to partecipate to these discussion and throw in my own point of view. I think it makes sense to republish it here. The following text is adapted from a longer comment I posted toa thread entitled Conversion from VB6 to VB.NET 2005 on DevX Forums.


 

I believe that the confusion about automatic code translators raises because most people expect that they work magically without any human intervention. Alas, this is the approach used by the Upgrade Wizard inside VS and this explains why it performs so poorly. In most real-world cases you can't simply run the tool on a piece of contorted VB6 code and have fully working VB.NET code at the first attempt. Instead, a real-world migration process is an iterative task.

A code translator should migrate your code according to *your* personal style and preferences. VB Migration Partner allows this by means of so-called "migration pragmas", which are special remarks that you embed in the original VB6 code. For example, this pragma tells VBMP that special code must be emitted so that the VB.NET can correctly handle default members even in late-bound mode (which is one of the main limitations of Upgrade Wizard):
    '## project: DefaultMemberSupport True
VBMP supports 60+ different pragmas to automate virtually every adjustment that might be needed after an initial quick-and-dirty migration. Pragmas are essential because they allow you to repeat the migration many times and still keep the VB6 and VB.NET code in sync, even if the migration process takes months.

VB Migration Partner can handle many recurring migration issues quite nicely. In most cases it can do it without human assistance, in the worst case it requires that you add a pragma.

Quoting a previous forum comment: "If you are crazy enough to spend 3 months to make a conversion work with a loss of performance compare to the VB6 application, while a 2 months rewrite would do the job and give you something that easier to maintain, go ahead."

With small projects this approach can make sense, provided that you can afford the extra time/cost and that you have a team that is adequately skilled in both VB6 and VB.NET. One of our customers is tackling one "monster" app of about 15 million lines scattered nearly 1500+ VB6 projects; the customer has estimated that it would take about 20 years/man to rewrite it from scratch, which they can't afford. They also estimated that VB Migration Partner will cut cost and time-to-market by at least 70-75%, which made their choice obvious. [NOTE: it later became clear that the actual savings was closer to 85-90%. The migration should be completed in a few months.]

The real value of a good converter such as ours is that an individual developer (or a team) can handle the migration process even if they aren't expert in either the source or the target language. VB Migration Partner contains a huge database of "good programming" rules as well as "obscure bugs" that are unknown to most developers, including a few expert ones. Let me make one simple example:

    Dim buffer As String
    buffer = Space(256)
    ' GetSystemDirectory API returns # of chars in the result string
    buffer = Left(buffer, GetSystemDirectory(buffer, 256))

This code works well in VB6 but delivers bogus results when translated as-is to VB.NET. VB Migration Partner correctly points to the issue and its solution. The question is: How many VB developers are aware of this subtle difference between the two languages? You might object that this code isn't representative of good VB programming, yet there are tons of code like it out there, and most "human converter" aren't skilled enough to find and fix it. (Here I talk from personal experience: it took hours to track down the problem the first time we bumped into it.)

Let me make one more example. In VB6 the default parameter passing mechanism is ByRef, which means that most methods take a byref argument only because the original developer forgot to add an explicit ByVal keyword. The problem is, VB.NET should use ByVal whenever possible because this coding style prevents a lot of compile and runtime errors. (You can have problems when passing an ADODB object to a byref parameter, and there are many other similar cases)

A developer doing the port or the rewrite, therefore, should carefully check each byref parameter and see whether it can be converted into ByVal without changing the code behavior, but this task takes days on a real-world app, because you'd have to check whether *each* parameter is modified, or passed to a method that modifies it, and so on recursively. VB Migration Partner does it automatically in a matter of seconds, emits a warning, and can optionally convert the ByRef into ByVal for you.

The code analysis engine in VB Migration Partner can do many other interesting things. It can remove unused methods, Declare, and Const statements; replace Exit Function with Return, merge DIM and assignments (eg Dim x As Integer = 1), suggest when a StringBuilder object could replace a set of concatenations, and so forth. Once again, all refactoring actions are optional and can be controlled via pragmas. An average developer can surely perform these task manually, but in practice it happens quite seldom because he or she can hardly afford the extra time that these activities require.

I could continue with more examples of how an automatic code converter can do a better job than developers. Not in all cases, but in a large percentage at least. If you are interested, you can find all docs, KB articles, videos, and code samples at www.vbmigration.com. (We provide both the original VB6 code and the resulting VB.NET code.)

As far as I know, we are the only migration tool authors who dare to expose all this information to the public *before* they purchase the product. I hope potential customers or just programmers who are curious about conversion technology will appreciate this "transparency" policy.



VB Migration Partner build 1.10.02

clock January 16, 2009 02:08

Yesterday we released VB Migration Partner version 1.10.02.

The main feature of this new build is the ability to generate a report that summarizes all the migration warnings in the current project and, even more important, explains what each warning means and how you can get rid of it. For more information, read my previous post on this topic.



Comments from a VB.NET consultant

clock January 7, 2009 04:22

When we began our work on VB Migration Partner, we were aware that we had to make our product much better than the Upgrade Wizard and other conversion tools on the market, and that we had to backup our product with first-class, knowledgeable, and swift tech support. We are delighted that our customers realize that our approach makes a big difference.

Here is the abridged version of a blog post by Jugo Arsovski, a VB.NET consultant who used the Upgrade Wizard and then our VB Migration Partner to migrate an VB6 application by one of his customers. (Boldface is mine.)

I started Visual Basic 2005 Upgrade Wizard and after few steps I had converted .NET application. Oh my god! It was the worst converted code I’ve ever seen in my life. I ended up with zillion errors and warnings. It was practically useless code. I really had no idea where to start from. Almost every line in the project was underlined with red or green. I spent about 5 hours just trying to clean it up so I could understand some errors better. With that 5 hours I spent I only got about 1/1000 way through it so that should say how bad it was.[...]

I installed the VB Migration Partner on my computer and then ran the application. You wouldn’t believe that I was used to the GUI after only two or three minutes. It was love on first sight. lol

I have not spent a single minute on reading the help files. It is so simple to use that it is an absolute delight to work with. Actually all I had to do was to open VB6 project and then to click the "Convert to .NET" toolbar button (F5). Yes it was that simple. Only two steps and I had the VB6 application converted.

I ended up with only 65 errors and 17 warnings. I believe it's worth mentioning that this is nontrivial project, involving thousands of executable lines, a lot of methods, classes, DLL's etc. I am telling you this so you clearly understand that the initial 65 errors are relatively few, and seeing that was a real revelation to me. If i judge by the time it took to convert this application then this tool is certainly for all kind of migrations, beginning with the small and progressing to the huge ones (even those with millions executable lines). [...]

All the errors were related to certain interface but, honestly, i didn't know how to handle it. That’s why I contacted the VB Migration Support. I must say that I was pleasantly surprised by their efficiency and quick response. Actually this is very interesting part. To my great satisfaction I was privileged to communicate with Mr. Francesco Balena. [...]  

Isn't it brilliant that the author also leads the tech support team? No doubt this gentleman knows very well, that support is so essential in overcoming the initial dismay for automatic conversion tools. He contacted me the next day after I sent him an email and answered a ton of questions including the most important one, how to fix the remaining 65 errors.

As you can guess I was able to fix all the errors in the next ten minutes after Francesco's answer and finally compile the VB.NET project. Yep! It worked like a charm

I clearly remember when Jago contacted our tech support. He asked several tough questions, so I decided to reply personally. He was having a problem with a 3rd-party GIS type library which exists in both COM and .NET versions. One of the interfaces in the COM version had to be mapped to the corresponding base class in the .NET version. He solved his problem by simply adding a PostProcess pragma to the original VB6 code.

Producing only 65 compile errors in a large project is a great accomplishment by itself, but the ability to eliminate most of these compilation errors with just one pragma tells even more about VB Migration Partner power.

In case you didn't notice, however, the most interesting part of this story is the very last sentence:  It worked like a charm. Cool

It confirms that converted VB.NET apps often works fine at the first run once you eliminate the (relatively few) compilation errors. This is only one of the 17 advantages of VB Migration Partner's support library



How flexible a migration tool can be?

clock January 6, 2009 03:53

VB Migration Partner has demonstrated to be able to deal even with the most intricate conversion issues. Nevertheless, at times even we at Code Architects are startled by the power and flexibility that its pragmas can provide.

First, some background. The AutoNew pragma can be applied to variables declared using the "As New" syntax, to ensure that they preserve the same semantics they have in the original VB6 code. Like most pragmas, the AutoNew pragma can be applied at the project-, file-, method-, and variable-level scope. Here's an example of a variable-level scoped pragma:

    '## col.AutoNew
    Dim col As New Collection

A few days ago, one of our customers asked whether it was possible to apply the AutoNew pragma to all the variables of type Collection, but not to variables of other types. According to official docs this isn't posible, and in fact our first answer was that it was necessary to insert a distinct AutoNew pragma for each and every Collection variable. Alas, the application contained so many Collection variables that this task would have taken a lot of time and would have cluttered the original VB6 code with too many pragmas.

Then we got the "a-ha" revelation!

The PreProcess pragma gives VB Migration Partner the ability to modify the VB6 code before it is parsed, therefore it is possible to use a carefully crafted PreProcess pragma to automatically insert an AutoNew pragma immediately before the declaration of a Collection variable that uses the As New syntax. Here's the pragma you need:

'## project:PreProcess "\b(Public|Private|Dim)\s+(?<name>\w+)\s+As\s+New\s+(VBA\.)?Collection\b", "'## ${name}.AutoNew\r\n$0", True

For example, when applied to the following VB6 code:

    Dim col As New Collection
    Dim col2 As New VBA.Collection
    Dim col3 As Collection
    Dim frm As New Form1

the above PreProcess pragma transforms it into the following piece of text:

    '## col.AutoNew
    Dim col As New Collection
    '## col2.AutoNew
    Dim col2 As New VBA.Collection
    Dim col3 As Collection
    Dim frm As New Form1

When VB Migration Partner parses this code, it learns that the col and col2 variables must preserve the auto-instancing semantics. Notice that the col3 variable isn't affected because it lacks the As New clause and that the frm variable isn't affected because it isn't of Collection type.

Problem solved! Wink