VB 6.0 TO VB .NET - what was your experience?

  • Thread starter Thread starter Tim Anderson
  • Start date Start date
T

Tim Anderson

I'm writing a paper on VB 6.0 to VB .Net migration. I'm looking for a couple
of comments from organizations that have done this. (If you went to C# or
some other place, that's fine but it's not what I'm focusing on here). If
you have any brief comments, I'd be most grateful if you could email them to
me; I'll make sure you are properly credited. Comments welcome here too of
course, but I'll need email for comments to quote.

Many thanks,

Tim
 
Do not use the Code Advisor.
I, and at least one other individual, have posted threads about a common
error in the Code Advisor, and nobody responds.
So either Code Advisor does not work, or there is no support, or both.
 
* "Howard Kaikow said:
Do not use the Code Advisor.
I, and at least one other individual, have posted threads about a common
error in the Code Advisor, and nobody responds.
So either Code Advisor does not work, or there is no support, or both.
Click to expand...

I never worked with this tool but I remember I got feedback that it
worked well for some people...
 
Howard,
I've used the Code Advisor on a number of VB6 projects with great success!

Unforunately it installed clean for me, so there is little I have to offer
in getting your setup problem to work. Have you tried calling Microsoft
Support directly with your setup problem, seeing as no one in the newsgroups
have any assistance to offer?

Just a thought
Jay

Howard Kaikow said:
Do not use the Code Advisor.
I, and at least one other individual, have posted threads about a common
error in the Code Advisor, and nobody responds.
So either Code Advisor does not work, or there is no support, or both.

--
http://www.standards.com/; See Howard Kaikow's web site.
Herfried K. Wagner said:
You will find some material here:

Micrososoft Visual Basic Code Advisor
Click to expand...
<URL:http://msdn.microsoft.com/library/en-us/dnvb600/html/vb6_FixItRuleTool.
Click to expand...
 
Tim,
As Herfried suggested, using the Code Advisor before you upgrade is a must,
it reduces the number of errors that you have after you upgrade.

I find if you have relatively clean VB6 code (which the Code Advisor helps
identify) using the upgrade wizard is a definite plus.

Due to the shift from object based programming in VB6 to object oriented
programming in VB.NET some suggest you simply rewrite (redesign). If your
VB6 programs aren't even object based, the migration may make less sense.

Most of my VB6 programs have been as close as possible to object oriented as
VB6 allows, so upgrading for me made sense. After I upgraded I slowly
refactor (http://www.refactoring.com) the upgraded project to better
leverage the OO features of .NET (inheritance & the framework itself).

Hope this helps
Jay
 
Hi People,

Is this not a little bit very far from the question from Tim and disturbing
his answer?

Cor
 
Cor,

* "Cor said:
Is this not a little bit very far from the question from Tim and disturbing
his answer?
Click to expand...

Isn't it alloed to post replies which are "a little4 bit very far from
the OP's question"? Don't play newsgroup police!

SCNR!!!
 
LOL
Don't play newsgroup police!
Click to expand...

However wrong person, I never said that to someone and you also know I never
have been.

We did not see this messages for months in this newsgroup, is that not
greath?

I only tried to bring the thread back to the question from Tim and now I see
I spoiled that also.

Cor
 
* "Cor said:
However wrong person, I never said that to someone and you also know I never
have been.

We did not see this messages for months in this newsgroup, is that not
greath?

I only tried to bring the thread back to the question from Tim and now I see
I spoiled that also.
Click to expand...

Sorry, hope you saw the "SCNR".
 
It is absolutely critical to first prepare the VB6 app so that the
upgrade wizard produces relatively clean code.

E.g.,

- Change all array lower bounds to 0.
- Remove control arrays.
- Limit usage of "As Form" and "As Control" (soft-binding).
- Examine code in Class_Terminate events (if cleanup is time or
sequence sensitive, then will need to re-code to work under the
.NET
GC).
- Check for missing parameter modifiers - ByVal/ByRef - since it's

easier to get these right before upgrading.
- Examine ParamArrays to ensure not using in a ByRef way.
- Some splitter controls can cause massive form problems after
conversion; remove these if a test conversion indicates a
problem.
 
Hello Tim,

We converted a fairly large enterprise application from vb6 to vb.net.

The VB6 project was ~150k lines of code (became ~400k lines once
converted due to the VB6 *.frms becoming code) and took around 5 man
years to develop.

It was split into :
- 3 applications using a total of ~150 forms
- user controls dll
- business object dll
- object manager dll
- data layer dll
- common code dll

I'd say the project pretty much followed VB6 best practices. We'd also
wrapped most of the system libraries and controls we were using -- I'd
hate to imagine what the conversion would have like were that not the
case.

We first attempted the conversion with Visual Studio 2002. The idea
was to keep the UI in VB6 and gradually move the dlls to dotnet. We
spent around 1 man month on this before giving up as COM interop was
too flaky. The annoying thing was that it *almost* worked, and then,
just as you'd see the end of tunnel, you'd hit a show stopper.

We then decided to wait for the promised improvements to the upgrade
Wizard and do the lot in one go. That turned out to be a year later
with the release of VS.Net 2003.

It took around 4 intense man months to complete the upgrade to the
point where it could be deployed and another man month to clean up the
remaining ActiveX gunk and sub-optimal VB6 compatibility code


In this kind of situation you can either a) be happy that an upgrade
option is available at all: a rewrite from scratch would probably have
taken a year (that said it would have been less contaminated by the
VB6 way of doing things and would have given us the option to consider
C#, Java or Python).

Or b) be pissed off that you need to go through an upgrade process in
the first place and that out of the initial 4 months around 2 were
wasted dealing with insufficiencies in the Upgrade Wizard and the
compatibility libraries (of the other 2 months, 1 was "acceptable"
conversion work and 1 was intensive conversion of years of VB6
experience into dotnet). I won't go into the details of all the pain
but most of it involved the UI.


To summarize:

- If you're converting code that doesn't depend on the UI or
interaction with ActiveX libraries the Upgrade path should be fairly
smooth (not instant by any means though).

- If your project has good seperation of dbase, business logic and UI
code the upgrade path may be considerably more cost-effective than a
re-write. But it's about as pleasant as returning from holiday to find
your home smashed up and spray painted...


Tim
 
Cor,
I don't follow you, Tim asked for comments on migrating from VB6 to VB.NET,
I gave him comments on migrating from VB6 to VB.NET. How is that "far from
the question"?

Granted he asked for email comments, however I normally make my thoughts
public this way others wanting to know what comments were made they would at
least be able to find mine.

I'm not seeing how any of the direct replies to Tim (including Howards
comments) were "far from the question".

Hope this helps
Jay
 
Hi Jay,

I got the idea that Tim would make a investigation about the experiences of
organizations what where the troubles and what where the good things when
they did the conversion from VB6 to VB.net

From his writing I got the idea, he was meaning large projects not one or
two programs.

The answers he got where in my eyes, advices how to overcome the trouble.
When it is for his own purpose, the answers are not wrong, however when Tim
is gathering information for a more widely usable report he can in my
opinion not do anything with the advices he got, before I wrote that
message.

When it (if my gues is right) had been the experiences with the code advisor
from those companies he would have been glad of course.

(I made a little mistake connecting it to your message, but that was because
yours was the last in it, it was not personally to you. I did not correct it
because I was hoping you did understand that.).

However, maybe I am very wrong.


Cor
 
Hi Jay,

I read top down, I mean a message as "tohear" wrote, that was what I thought
as was wanted.

Cor
 
Cor said:
I got the idea that Tim would make a investigation about the experiences of
organizations what where the troubles and what where the good things when
they did the conversion from VB6 to VB.net

From his writing I got the idea, he was meaning large projects not one or
two programs.
Click to expand...

Yes, exactly right.
The answers he got where in my eyes, advices how to overcome the trouble.
When it is for his own purpose, the answers are not wrong, however when Tim
is gathering information for a more widely usable report he can in my
opinion not do anything with the advices he got, before I wrote that
message.
Click to expand...

It's a hazard of the newsgroups unfortunately.

Many thanks,

Tim
 
* "Cor said:
I got the idea that Tim would make a investigation about the experiences of
organizations what where the troubles and what where the good things when
they did the conversion from VB6 to VB.net

From his writing I got the idea, he was meaning large projects not one or
two programs.
Click to expand...

What's the problem if people post information related to the topic?
The answers he got where in my eyes, advices how to overcome the trouble.
Click to expand...

This is true, but, as said before, it IMO doesn't matter.
When it is for his own purpose, the answers are not wrong, however when Tim
is gathering information for a more widely usable report he can in my
opinion not do anything with the advices he got, before I wrote that
message.
Click to expand...

The point is that not only tim is reading this group, other people are
reading this group too and want to easily find information related to
the problem.
 
Herfried,
This is true, but, as said before, it IMO doesn't matter.

The point is that not only tim is reading this group, other people are
reading this group too and want to easily find information related to
the problem.
Click to expand...
Have a look at this URL for that,

http://tinyurl.com/2sfju

In my opinion there is more than enough general information there and that
could only be better if in this case the answers where more pointed to the
question from Tim.

Now it is only harder to find in this URL.

(Although the answer from Jay was in between, because he was telling about
how he did it, what there was not, was about the problems there were when
he was doing it)

:-)

Cor
 
Cor,
From his writing I got the idea, he was meaning large projects not one or
two programs.
Click to expand...
The programs I migrated that I was referring to specifically are very large
projects. Remember that large projects can be a single program (or even a
single assembly). One of the projects has in excess of 150 VB6 classes.
(like I said as OO as VB6 allows).
The answers he got where in my eyes, advices how to overcome the trouble.
Click to expand...
My answer was how I approached the migration. I initially did both
migrations without the Code Advisor. The project I wrote in an OO manor
migrated very easily & quickly. The other project required a lot of work. As
a test I ran Code Advisor on the other project, then upgraded it, it
required less work. Of course part of the 'less work' is simply do you do
your clean up in VB6 or do you do your clean up in VB.NET. The other project
was done by other people using what they felt were "best practices" at the
time...

Hope this helps
Jay
 
Back
Top