[WHITE PAPER] 17 Reasons for using a support library in migration scenarios

clock December 31, 2008 07:04

Unlike the majority of the language conversion products available on the market – which mainly attempt to convert code from one language to another – VB Migration Partner both converts the code and uses a support library to decrease the gap between VB6 and VB.NET and to ensure that the converted code really behaves as expected. When combined with its superior code parser and generation engine, the support library becomes an essential factor in VB Migration Parter's superior performance and high success ratio.

Using a support library in a migrated project isn't different from, say, using a 3rd-pary ActiveX control or a .NET control in your code. VBers have used custom controls for years, even if their source code wasn't available or consisted of poorly documented C++ code. VB developers have used 3rd-party custom controls because they didn't want to reinvent the wheel, they didn't want to spend months just to build a powerful grid or chart control, and preferred to invest their time and money on developing the real application, not just the infrastructure.

A support library offers pretty much the same advantages: it allows you to cut the cost of the migration process and bring the migrated VB.NET to the market earlier. As a matter of fact, a support library provides at least 17 important benefits.

Interestingly, our competitors felt the urge to comment our approach, in the attempt to convince potential customers that a library is a very scary thing. Their arguments are a bit lame, though, if you consider that their tool uses a support library for specific tasks, except their library isn't as complete as ours.

The truth is quite different, of course: a rich support library provides so many advantages that it would be silly NOT to use it. The advantages are so many and so important that we wrote a detailed white paper to describe them. Read it, compare it with what our competitors opinion, and then decide for yourself.

Have a great new 2009! Cool



Need help in decoding migration warnings?

clock December 27, 2008 10:11

Providing tech support to customers located all over the world isn't a simple task. Not only do you have to answer their questions, you also need to do it in a timely manner, because if they are stuck with a problem then the migration process is going to be delayed until we come up with a solution. As one of our customers has noticed, we often provide the solution in a matter of hours, which means that we are quite efficient, but ideally we'd like to provide istantaneous reply.

One way to help our users is to provide as much documentation as possible. VB Migration Partner's manual is online for all to see, as is a very complete knowledge base and a VB6-vs-VB.NET section where you can read about *all* the differences - documented or not - between the two languages. Traffic analysis shows that these sections, especially the last one, receive many visits from all over the world. Most of visitors aren't our customers, which is great because we like to offer this service to the VB community. Perhaps some visitors are using a tool from our competitors, which is understandable because we carry information that can't be found anywhere else. 

We noticed that many common questions are related to migration errors and warnings. Like the Upgrade Wizard, our VB Migration Partner produces a number of inline UPGRADE_ISSUE, UPGRADE_WARNING, UPGRADE_INFO, and UPGRADE_TODO remark. Unlike the Upgrade Wizard, the remark doesn't include the URL of a page that explains what the error means and how it can be fixed. Frankly, in most cases the Upgrade Wizard doesn't really shine in this respect, therefore we don't want to take it as a model. Regardless, it was a behavior we wanted to emulate.

It took a while (and a lot of writing), but at last we have a page where you can ask for detailed information about a migration error or warning code.  Just click here and type one or more error codes in the field at the top of the page.

We went further than that, though. In forthcoming version 1.10.02 you will be able to produce a report that explains in detail all the warnings and issues produced by the VB6 project just migrated:

 

This command runs Internet Explorer (or your default browser) and displays info on all the errors and warnings in the project. Here's an example of what you get: 



Notice that the command sends a list of error codes (and the number of their occurrences) to our website. We opted for this arrangement (instead of storing the info locally) so that we can continuously improve the documentation. Most entries are small articles or contain links to KB articles or the pages in the manual where you can find more info about the specific problem.

If you have suggestions on how we can make this service even more useful, just let us know. 



Feedback on VB Migration Partner's support

clock December 22, 2008 12:57

A good migration tool would be nothing without an adequate tech support. That's why we invest all our energies to answer our customers' request as quickly as possible. At times this is difficult because we have so many customers overseas. At times we work on Saturdays so that everything works fine on Monday morning. I personally write the majority of KB articles, to share our knowledge among users and make our tool easier to use. 

It's a lot of effort, but it's so rewarding when a customer gives us such a great feedback:

Structural Concepts Ltd. has been developing Virtual Bridges for over 10 years. The unique next generation bridge engineering software is being used on a number of notable projects and design competitions.

In order to take advantage of the increased available memory in MS Vista 64 as well as to take advantage of multi-core processors, the large VB6 software base is being migrated to MS Visual Studio.Net. It was important to proceed in an efficient manner while still being able to continue using and expanding the existing version of Virtual Bridges. While the architecture of the software was very well thought out, any thought of carrying out the migration process manually or with partial conversion tools would have been out of the question. Although proceeding step by step using COM interopt was initially contemplated, it quickly became apparent that the process and debugging worflow would be too inefficient.

By some luck, I came accross VB Migration Partner's web site. Based on prior first hand knowledge of Francesco Balena's excellent VB text books, I was sold even before the product was released. Once it was released, I immediately purchased it and put it to good use.

This is the part I like most. (The boldface is mine.)

It is absolutely clear that VBMP is an essential tool for the migration of any real project. Frankly, given the exemplary support from the lead developer and author of in my opinion the finest VB textbooks out there, I could only proceed with full confidence. Given that any issue that I raised was answered positively on a next day if not next hour basis also made a huge difference. It's really as close to having VB Migration Partner's support team work in my office as one could get!

Ara Ashikian, P.Eng.
President, Structural Concepts Ltd
Vancouver, BC
Canada

It's worth noticing that Structural Concepts is migrating a VB6 app to VB.NET while extending and updating the VB6 code at the same time. This is the kind of wonder that only VB Migration Partner's convert-test-fix methodology can offer. No other VB6 conversion tool even comes close.



More on binary compatibility

clock December 20, 2008 06:11

A reader of a previous post on binary compatibility asked for clarification about my claim about VB Migration Partner being the the only conversion tool on the market offering this important feature, mentioning that at least another tool from our competitors also claim to offer this feature, which they obtain by adding ComVisible, ProgID, and ClassInterface attributes.

I am aware there is some margin for ambiguity and for uncorrect information, so I decided to drill a bit deeper on this topic.

You have binary compatibility between a COM component a .NET component if you can unregister the COM component and install the .NET component in its place, without having to recompile the COM clients that were using the COM component. We call it "binary compatibility" because it's the kind of compatibility we used to enforce under VB6, to ensure that a new version of a given component was perfectly compatible with its previous releases.

The ability to generate a VB.NET component that is binary-compatible with the original VB6 component is greatly useful, for many reasons:

  • You can migrate a complex N-tier application starting with its innermost DLLs, typically those that access the database, without having to recompile or modify in any way existing COM clients. 
  • The ability to convert only a subset of existing DLLs without being forced to migrate the entire application allows you to focus on those components that suffer most from the inherent scalability and performance limitations imposed by COM. This is the so-called phased migration.
  • Just as important, you can immediately debug the converted DLLs because you can use existing COM clients and their user interface - no need to write small throw-away .NET projects with the only purpose of testing the DLLs you just converted.
  • Finally, if your organization is very serious about testing, odds are that you have defined unit tests, use cases, and maybe scripts that rely on commercial testing tools. The great news is that, in most cases, binary compatibility allows you to test the converted DLLs using existing unit tests and scripts, thus saving you even more time.

As you see, binary compatibility can be a tremendous time-saver when migrating a VB6 application that is split in many DLLs, and it's no surprise that a migration tool vendor would like to claim that its product offers this feature.

Unfortunately for our competitors, to generate a .NET class that is binary-compatible with the original VB6 class you need much more than three attributes. You have to extract GUIDs from the original DLL and apply them correctly to the generated .NET class, you must handle fields, enums, types, events, and interfaces with special care, and you have to pay attention to many special cases and exceptions.

More precisely if you just add the ComVisible, ProgID, and ClassInterface attributes, the best you can get is compatibility with existing VBScript and ASP clients, not with compiled COM clients 

The bottom line: based on what I can read and what I heard from customers, I can only reinforce my claim that only VB Migration Partner offers true backward binary-compatibility with existing COM clients and fully supports phased migrations of N-tier VB6 apps.



Version 1.10 is here!

clock December 5, 2008 08:55

We just made version 1.10 available to all registered users.

We released the 1.10 BETA version about five weeks ago, thus it took longer that we expected, partly because the many new features in 1.10 had to refined and partly because we decided to include a few features that were planned for a future release, such as support for the BinaryCompatibility pragma and for blindly fast collections. Of course we also took the opportunity to fix some serious and less serious bugs (I just counted 58 fixed bugs in the VersionHistory.txt file). 

With version 1.10, VB Migration Partner is more powerful than ever and is ready to face even the largest and most intricate VB6 applications. A few of our customers are converting applications with hundreds of distinct projects and several millions lines of code. More about that in a future post.