Migrating form vb6 to VB2005...

[ksw1069]

I am yet another VB6 developer faced with converting a VB6 app to VB2005. I've gone through the wizard that came up with a ton of issues that couldn't be upgraded. Is there a resource I can use to give me some assistance as to what the "new" way of doing something in VB2005 that was done in VB6 ???

I really don't know where to start researching how to now handle some of the stuff from VB6 to VB2005... The tutorial walked me through some specific things, but is there a place I can go to give me other conversion issues?

Thanks in advance...

 

[SiriusBlackOp]

As you found out, the wizard only gives you a partial solution. You will have to know VB.NET in order to upgrade it properly. The conversion wizard is really not very smart and has very likely created a very poor .NET design and sometimes it is best to start over. VB6 and VB.NET are Very Different animals.

Bottom line, you have to learn VB.NET before you can build a VB.NET application.

There is a book I used and recommend pretty often called "Moving to VB.NET" and it is written for VB6 programmers who are starting to learn VB.NET.

http://www.amazon.com/Moving-VB-NET-Strategies-Concepts/dp/1893115976

Last I read that book it was based on VB2003, so there are some additional tools and namespaces in 2005 that may not be in the book like the "My" namespace.


Senior Software Developer

http://www.scoutsft.com

 

[mmilan]

I'm currently in the initial stages of starting to migrate a large application (600 modules, about 50 Active X DLLs) over to DotNet. I agree with the comment above about the Upgrade Wizard being a dead loss - one of our former coders was inordinately fond of the GoSub construct in VB6 - which isn't in VB2005... How does the upgrade wizard handle the problem? That's right - it replaces each call to the subroutine with the body of the sub-routine! Nice! Don't implement a private sub and pass arguments in by reference - nah - that'd be too obvious, wouldn't it?

My advice, by a decent book, and read it. I bought one on VB2005 by Tim Patrick, and I *REALLY* liked his style - the book was a pleasure to read, and the guy knows what he's talking about...

Also, play around with things, and use Google lots!

Personally, the issues we're finding to be a pain (though a good idea in terms of project design) are:

* No Gosubs
* VB6 passed arguments ByRef by default - where as VB2005 uses ByVal
* Strings - there is a VB Compatibility library to give you the functions you know and love (like left(), right() etc), but that's cheating... Using strings properly (via their methods / static methods) needs a bit of acclimatisation, but it's worth it.
* ADO.NET - Totally different - but not too bad once you work through an example.

Things I love about VB2005.
* Inheritance - Finally, proper OOP comes to the VB World (though previous versions of DotNet also had it)
* Generic functions / classes - we're you can pass the type of an argument into a function together with it's value, and it will be treated as that type inside the function.
* Regular Expressions - A pain in the behind to begin with, but *well* worth the effort.
* Ability to easily use libraries written in any other DotNet Language.

My advice - get stuck in...

 

[SiriusBlackOp]

600 Modules!!?!?!?!??!?

OMG - Kill me Now!!! LMAO!!

Modules are always about the first things I try to eliminate in a conversion project. They have a real knack for creating spaghetti code.

Senior Software Developer

http://www.scoutsft.com

 

[mmilan]

Well, I'm calling forms and classes modules as well here - "modules of code" if you want to be accurate...

It's probably somewhere in the region of about 250 forms, 200 or so bas modules, say a hundred classes... As I said, it's a big project.

We've thrown a commerical project analyzer at it in order to try and identify co-dependent modules of code, and that program broke down and cried trying to find the 4th level dependencies... Let this be a warning to those of us who like software to "evolve"...

As things stand, I am seriously beginning to consider writing my own code to try and handle the dependence issues on a function by function basis. It's a task that would earn me the undying love and respect of my managers, but probably send me mad in the attempt!

Back to the OP though - as I've said, play with it... Consider C# as well - and at the very least try to get a feel for the language as you broaden your experience in the DotNet framework... It's mainly just syntax...

Martin

 

[shannanl]

I started and stopped trying to learn vb.net several times before I bit the bullet and converted from VB-6. I am by no means a pro, but I am able to write .net programs from the ground up now. At first it will seem that the changes they made make no sense. Some still do not to me but after you grasp it you will never want to go back to VB-6.

Hang in there.

 

[shannanl]

As a p.s. - I had about a dozen programs in VB-6 and tried to convert some of those. The small programs are not that bad but I gave up on the larger ones. I left them in 6 and started all my new stuff in .net. Converting is almost like rewriting the entire program if you switch completely to .net.

 

[mmilan]

The approach my firm is hoping to take is basically "Cut, Paste, Fix, Repeat."

Given a free reign, I would have gone for a writing a whole new product...

Martin.