Conversion tool comparisons for visual basic 6.0 [closed]

Answer 1

The problem is that the conversion tools don't offer support for the VB6 Graphics commands or the VB6 printer model. Plus you get into a lot of corner cases when dealing with ActiveX controls. I know our own CAD/CAM applications won't translate over with any conversion tools as a lot of tweaks are built into the UI to make it work smoothly with the VB6 Form Engine.

These are things that conversion tools fail on as the WinForm Engine requires it's own tweaks. The same thing was experienced when our software moved from DOS to VB3. Sometimes there is no substitution for manual conversion.

With that being said, there are somethings you can do to make conversion considerably easy. First make sure your application is built in layers. This way you can convert one layer at a time, test and continue on. It also has the advantage of leaving you with usable software at every step. I recommend starting at the top (form) layer and working your way down.

Make sure anything that is VB6 centric and not Basic Centric is behind an interface. When .NET first came out several years ago I created a Canvas Interface and implemented that using the VB6 graphics command. I use the same Canvas interface in VB.NET except now it uses the Graphics Object. The same was done for printers.

Nearly all the code was moved out of our forms into classes that the forms called. The forms themselves implement an interface that the UI Classes used. When we switched to .NET we have a precise definition of how the form interacted with the rest of the system and form conversion was considerably easier.

All of these steps where done in VB6 and put through our normal release Q&A process. Then afterward we started the conversion.

Answer 2

I think you've already seen the question about tools for migrating VB6 to VB.NET.

Both have published special offer prices for the UK market on their basic products on this Microsoft UK page. Of course you need to know the limitations of the basic products and the prices for your market to make a realistic judgement, so you probably do need to contact them :(

• Artinsoft Upgrade Companion Developer Edition £199 for up to 50,000 lines of code. EDIT Now offering a free version that can do up to 10,000 lines of code.
• Code Architects’ Visual Basic Migration Partner Professional Edition £399. They told me this was also for up to 50,000 lines of code.

The built-in Microsoft upgrade wizard is pathetic - according to the guy who wrote it - of course he is from Artinsoft so he wants to sell you something better. Microsoft UK also say the Artinsoft and Code Architects tools are better than the built-in upgrade wizard.

EDIT: I contacted Code Architects for a quote, they responded very fast. Unlike this Stack Overflow question by Angry Hacker who had a worse experience. But then Francesco Balena popped up on Stack Overflow to answer his question within 12 hours, which is more encouraging.

Answer 3

I am Eugenio La Mesa, general manager at Code Architects. I read a few comments on our VB Migration Partner and conversion tools in general, and thought I might add some hopefully useful hints.

First, our conversion software does support all VB6 graphic properties and methods – with the only exception of DrawMode and ClipControls. We even support the AutoRedraw property and user-defined ScaleMode coordinates, therefore the migration of a CAD-like program to VB.NET is quite in the reach of our software. The Code Sample section at www.vbmigration.com contains many examples of graphic-intensive VB6 apps that have been converted to .NET with minimal effort.

Second, let me clarify our price structure. We sell two different editions of VB Migration Partner: the Professional Edition can convert VB6 apps with max. 50,000 lines of code, whereas the Enterprise Edition has no size limitation and supports a few additional advanced features, such as integration with source code control software and generation of .NET components that are binary-compatible with the original VB6 DLL, which allows you to implement staged migrations of N-tiered COM-based applications.

The price of the Professional Edition for £399 is a special promotion up to June 30th 2009, during a Microsoft UK marketing campaign, for UK only and for applications up to 50K lines of code (LOCs). The price of the Enterprise Edition may vary because it depends on several factors, including number of licenses and number of LOCs to be migrated. This explains why you may see different price quotations. Also, we have recently slightly decreased the list price as our answer to the economic situation. We are also planning to take a few features out of the main product and offer them separately, which would result in a more flexible price structure.

Quite honestly, for applications with 25-50K LOCs we usually recommend a manual rewrite. In fact, our focus is on the enterprise market segment, where you often finds VB6 apps with several hundred thousand LOCs, if not millions. In those cases, a manual rewrite is seldom a viable option: it requires too many skilled VB6/.NET developers, it takes too long, or just costs too much. We have recently published a case study related to an application with 650K LOCs; one of our customers is currently migrating a monster app with about 15 million LOCs!

Answer 4

I was quoted $2500 for the professional edition of vb migration partner last year. I didn't buy it so I can comment on it

Answer 5

I haven't used either of the tools mentioned, but with a little preparation, the upgrade tools in Visual Studio are more than adequate.

The first thing you need to do is get the Visual Basic 6 Code Advisor from Microsoft. It's a great help in getting your project ready for migration.

Answer 6

"updrading" VB6 to .NET is a misnomer. All you get is VB6 code in .NET; generally you can get much better results with a refactor/re-architecture - using a different class model, for example. Perhaps designing to be unit-testable, for example. Or using IoC.

If you just want the code to work (and you're confident you can test it), then fine.

Personally, I would seriously consider a more manual port. And I have a lot of legacy VB6 code, so I know the pain involved.

Every time we've faced this, we've simply re-written it in C# - as an approach, it has proven itself many times over.

Actually - I recommend Brownfield Application Deveopment (Manning) - it may give some valuable insights on things to have in place before you start.