1

Possible Duplicate:
Best Strategy for moving from VB6 to .NET
Conversion tool comparisons for visual basic 6.0

Is there a good tool anyone can recommend to convert a commercial VB6 application into a VB.NET application. I have discovered some free ones and some commercial one's, but can't find any reviews and opinions of developers who have tried and failed or tried and succeeded.

What are the complexities involved? I know that .NET uses managed code and multi threaded apartments etc whereas VB6 is based on COM.

Community
  • 1
  • 1
w0051977
  • 15,099
  • 32
  • 152
  • 329
  • 2
    .NET applications support STA just fine. Unfortunately, [shopping questions are off-topic for Stack Overflow](http://blog.stackoverflow.com/2010/11/qa-is-hard-lets-go-shopping/). – Cody Gray - on strike Apr 20 '12 at 20:20
  • @Cody Gray, thanks for the suggestion. I have already read the page: shopping questions are off-topic for Stack Overflow. I am specifically asking about developers experiences upgrading rather than how to upgrade. – w0051977 Apr 20 '12 at 20:26
  • Then also browse the [FAQ]: open-ended and discussion-based questions don't work here, either. – Cody Gray - on strike Apr 20 '12 at 20:26
  • @Cody Gray thanks for the second link. It was useful. – w0051977 Apr 20 '12 at 20:34

4 Answers4

4

Don't do it. Don't convert. Do a re-write. Sorry, but even though the code CAN be converted, it doesn't mean it should be converted.

Please, in the name of cleaner code everywhere, spend the resource time to have it written correctly. View this as an opportunity to clean up the code, and take advantage of everything .Net brings to the table....

And I really don't care if I get negative rep'd on this one. If I convince one company to rewrite instead of convert, it was worth it.

Lynn Crumbling
  • 12,985
  • 8
  • 57
  • 95
  • 1
    I agree with this. Have you ever upgraded (not rewritten) and if so; what were the complications? – w0051977 Apr 20 '12 at 20:33
  • I've seen outputted code. It's not so much a matter of complications, as it is about going from a language that doesn't focus on OOP to a language designed around it, but having the converted code be "flat" in the sense that there's ONE CLASS that EVERYTHING lives in. – Lynn Crumbling Apr 20 '12 at 20:36
  • 1
    I see. Object Orientation is the way forward rather than Object Based. The VB6 application in question has many classes (54). Are you saying that they will all by merged into one with the tool you used? – w0051977 Apr 20 '12 at 20:38
  • It bodes well if your existing app actually has business logic separated into class files already, and code consumes those AS OBJECTS (via new). I suspect most implementations of converters will deal with these correctly and make new class files. It sounds like your code is above par when compared to most classic vb code, which does not tend to use classes. I can't speak directly about various converting products, but I suspect most would keep classes as classes. – Lynn Crumbling Apr 20 '12 at 20:44
  • 4
    This is **much too sweeping**. Some VB6 apps have millions of lines of code and have many developer-years invested in them. With all respect, it's just absurdly naive to say you should **always** rewrite. – MarkJ Apr 21 '12 at 05:42
  • I completely disagree; in the long run, the benefit of being able to reuse objects created during the rewrite will lead towards more easily maintainable code and a MUCH better organization of business logic. My stance has nothing to do with naivity, and everything to do with doing things "the right way" instead of some hack. – Lynn Crumbling Feb 23 '13 at 21:54
3

This is a copy of my answer to the duplicate question (as CW) because I want to reply to the "always rewrite" answer that's currently top-voted here.

My advice is don't underestimate the effort of conversion - be very cautious about embarking on a rewrite. It's a common pitfall to start out optimistically, make good early progress fixing some of the well-known flaws in the old architecture, and then get bogged down in the functionality that you've just been taking for granted for years. At this point your management begin to get twitchy and everything can get very uncomfortable.

...and here's a blog post by a Microsofty that somewhat agrees with me:

Many companies I worked with in the early days of .NET looked first at rewriting driven in part by a strong desire to improve the underlying architecture and code structures at the same time as they moved to .NET. Unfortunately many of those projects ran into difficulty and several were never completed. The problem they were trying to solve was too large .....

Hence I quickly became a fan of Migrate or Reuse as the right approach for most companies. Interestingly though, Rewrite is a less risky option than it once was. Many companies who still have significant VB6 projects also now have strong .NET skills gained on other projects, improved software development practices (including automated tests – a must IMHO for Rewrite) and have even taken the time to refactor elements of their VB6 codebase over the last 6 years. That said, I would still place Rewrite below Migrate or Reuse for most companies.

Quote from an excellent Microsoft webpage

Performing a complete rewrite to .NET is far more costly and difficult to do well [than converting] ... we would only recommend this approach for a small number of situations.

Also the renowned VB expert Dan Appleman said:

In most cases porting [VB6 to VB.NET] is stupid and a complete waste of money.

And Joel said a while back:

The single worst strategic mistake that any software company can make [is to] decide to rewrite the code from scratch.

A couple of other useful links about migration including links to another free book from Microsoft. One. Two. Three.
Microsoft page including screencast with their answer to "how to migrate"

Community
  • 1
  • 1
MarkJ
  • 30,070
  • 5
  • 68
  • 111
  • 1
    +1 can I get your quick opinion on VBA to VSTO upgrades, do you think small VBA projects are worth converting? and what happens if (or when) the VB6 runtime wont run on the latest Microsoft OS? Then a lot companies will have no choice either upgrade or use an old OS. – Jeremy Thompson Apr 21 '12 at 09:24
  • 1
    Any small project you could think about rewrite. I don't know anything about VSTO, sorry – MarkJ Apr 21 '12 at 12:46
1

Just about any free tool will do a decent job of converting the code. The result that you get is not really good whatever tool you use, because VB.NET code is quite different from VB6 code, despite the syntax similarities. Even if you use a translation tool, you should make a thorough cleanup of the code.

Guffa
  • 687,336
  • 108
  • 737
  • 1,005
  • 2
    There's only one free tool that I know of - Microsoft's - and its underwhelming. It leaves a lot to be done manually. Which ones are you thinking of? And I would advise any code cleanup should be done pragmatically, focussing on code that needs to be changed, like any refactoring of legacy code. Any thorough cleanup needs to provide savings to pay its way. Theres a danger of investing time cleaning code that is unlikely to be changed. – MarkJ Apr 21 '12 at 05:46
1

Visual Studio has an integrated conversion tool in menu File > Open > Convert....

If your VB6 project is well structured and well commented and you are an expert in both languages (VB6 and VB.NET), you can give it a try, otherwise the conversion could become a nightmare. In any case you will have to fix many things manually after the conversion.

Googling Language Changes for Visual Basic 6.0 Users will give you useful links covering the differences between the two languages.

Olivier Jacot-Descombes
  • 104,806
  • 13
  • 138
  • 188
  • 2
    It's worth considering the commercial conversion tools too. They exist because Microsoft's conversion tool leaves so much to be done manually. Worth a look if you have a large amount of VB6 – MarkJ Apr 21 '12 at 05:52
  • The conversion tool only exists in Visual Studio 2008 and earlier. It [was removed](http://msdn.microsoft.com/en-us/vstudio//ms788233) in Visual Studio 2010. – MarkJ Jul 07 '12 at 19:30