[RESOLVED] Converting vb6 to vb2010

Quote:

---

Originally Posted by Negative0

Most conversion tools will still use VB6 syntax

---

And so don't many people coming to .NET from VB6 - drives me nuts.

Rewrite your program from scratch using all .NET syntax and not legacy VB6 syntax still supported in the .NET world.

I would put forward that the conversion process will do very little if anything to further any understanding of the .net world. The frustration will probably destroy any potential gains you get from the process.

I appreciate the quick and meaningful responses. I am convinced now to manually convert it and feel confident there will be plenty of timely help on the forum if needed. Hopefully, after this is done, I will be able to help others along the same struggle.

Thanks,

Jerry

I have a comprehensive program I previously developed in vb6 and ready to convert into vb2010, both as a learning tool about vbnet and to proceed with the development of the program.

In searching the web, I found some conversion software that could be loaded but after searching the forum, it was said that even the best conversions are problematic.

The advantage of an automatic conversion is that since I am a novice in the net world and not yet familiar with the new syntax and resources, a bad conversion might point out a number of unknown commands that I can clean up as a learning project.

The advantage of converting by hand is that the software can be reorganized and improved on during the conversion but not being familiar with all the possibilities might make this approach clumsy.

I want to roll up my sleeves and learn all I can in the conversion. Any suggestions on which approach would be the best or what to do to make the automatic conversion will really be appreciated.

Thanks,

Jerry

Here's a metaphor. Consider translating one programming language to another to be like translating text from one human language to another. It's easy to translate things like "My name is Sitten Spynne, I speak a little French" to "Mon nom est Sitten Spynne, je parle un peu français." These are simple sentences with no subtleties. But suppose I want to translate a joke that relies on language structure: "Farmers earn a meager celery." In English, that sentence only makes sense because "celery" and "salary" sound alike. In French, "céleri" is pronounced quite differently than "salaire", so the direct translation looks stupid and the more correct translation loses the joke; it's untranslatable as-is. It gets even worse when you consider sentences with *very* complicated use of grammar like "Buffalo buffalo Buffalo buffalo buffalo buffalo Buffalo buffalo". To get a decent other-language translation, you first have to translate it from English to English: "The buffalo from Buffalo who are buffaloed by buffalo from Buffalo, buffalo other buffalo from Buffalo." Then there's word salad; gramatically correct sentences that have no meaning: "Colorless green ideas sleep furiously." You can find this stuff in poetry, literature, and many other large bodies of text and it's often impossible to translate these works without losing some of their original meaning.

This happens when computers try to convert program code. Programming languages can be parsed and analyzed by computers because they satisfy some distinct properties you can read about by studying formal languages. However, there's often a good bit of human intuition attached to the code. Perhaps some code exists because VB6 doesn't have feature X, but VB .NET has it. The converter won't know and you'll get to carry the burden of useless code. Perhaps .NET has some feature Y that makes task Z easier; the converter can't know this and will leave it as-is. When you hire a .NET developer to work on this, they'll stumble when they hit these pockets of weird code. A good developer knows better than to touch code that isn't well-understood. In my experience, these machine-converted projects are never slowly converted into hand-written .NET projects. There was no time to do the conversion in the past and the time to do it is never done in the future. Managers don't want to hear you say "let's delay some features so we can clean up some code". The trouble is, you tend to accumulate some bad code designed to work around the problems with the other bad code. Eventually, it can be so hard to implement a new feature you have to rewrite the project anyway.

There are techniques for managing legacy code, and if you follow them carefully you won't have as many problems. But be wary. The graveyards are littered with companies that decided to do cheap translations of their mission-critical software. The long-term costs are almost always greater than the short-term costs.

My suggestion is to do it all manually, then you actually learn the .NET language. Also I've seen output from some of these VB6 to .NET converters and some of the generated code is still legacy VB6 code. That's why we are here too, we can tell you the most .NET way of re-writing your VB6 code.

Rewrite it in .Net. Most conversion tools will still use VB6 syntax and a lot of what you glean from the conversion will be poor practices if you were writing brand new .Net code. This will give you a chance to reorganize your code and really utilize all of the great features that the framework offers over what was available in vb6.

In case someone is wondering why my post and SJWhitely's post is ahead of the thread starter, it is because the time on the VBF server was off.

This has been corrected.

I appreciate the thoughtful replies. How do I mark this resolved? I don't see a way to do it. I marked another post resolved but can't remember how I did it.

Thanks to everyone,

Jerry

It's under thread tools