The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

VB6 to VB.Net 2005

Sort of similar to Rajeev's topic in JoS:

We have a large app in VB6 now using several 3rd party controls.  It's time to move it to .Net 2005 along with a complete refactoring of the codebase and the database (currently SQL Server 2000) behind it.

We are looking for success and horror stories, and advice.  We would like to hire someone on a consulting basis to discuss in detail our current situation and our desired endpoint.

Where do we find the guru?
Karl Perry Send private email
Tuesday, December 05, 2006
 
 
Why not vb to C# I think the effort is about the same.  I am MCAD.Net and have wrestled with this issue a lot.  The VB guys I have talked with feel that the learning curve is about the same...and over the past 3 years I am getting the sense that c# is the more popular.
Send private email
Tuesday, December 05, 2006
 
 
The amount of effort involved in migrating your code is probably less than rewriting the entire application from scratch. There is no upgrade to VB6, that's just Microsoft marketing and wishful thinking.

What are the reasons for changing?
pick a number
Wednesday, December 06, 2006
 
 
more not less
pick a number
Wednesday, December 06, 2006
 
 
>> Where do we find the guru?

Which country are you in? There are plenty of gurus with experience of migrating Visual Basic 6 to Visual Basic 2005 around (I’m one), if you’re in the UK.
Mike Green Send private email
Wednesday, December 06, 2006
 
 
"The amount of effort involved in migrating your code is probably [more] than rewriting the entire application from scratch."

How do you figure?
Jake
Wednesday, December 06, 2006
 
 
Thanks for the replies so far.

C#: We have zillions of LOC in our app suite.  Converting from VB to C# means absolutely that every line must be rewritten.  We have lots of code that will have to be refactored - rewritten - in VB but also a lot of code that won't - business process code, not interface code.  I'm concerned that for a small company, a hybrid of "some code VB"/"some code C#" won't work well.  We're going to have a hard enough time converting from VB6 to VB.NET and refactoring our DB, never mind having to learn a whole new language too.

Why do it?

1. I'm not a VB expert (I used Delphi prior to making the jump to sales/admin) but the VB experts I've spoken with have told me there are "things" that can't be done in VB6, or that are so much harder in VB6 vs. .NET that switching to .NET makes more sense.

2. Just like every other technology-related thingy in this world, life moves on.  It's time for us to put VB6 away.  And please: I don't want this thread turned into a "you can/you can't do everything with VB6" argument.  We're moving to the .NET platform, that's decided.  We need advice about getting that done, not about whether to do it.

Where are we?  Near Seattle.  Because of time differences I doubt working with a European consultant would work.
Karl Perry Send private email
Wednesday, December 06, 2006
 
 
In your shoes, Karl, assuming (as you say) that the decision to move to .NET is a fait accompli, I'd focus on learning about interop between COM and .NET.  (Google on "calling .NET from COM".)

Nothing can be more discouraging than working on a big huge untested code base and being unable to get it working.  Therefore I'd focus on taking the tiniest pieces you can and moving them to .NET.  That will place some restrictions on the way you code in .NET, but it has the distinct advantage of letting you migrate and test in small units so you can keep everything working as you migrate.  Eventually the goal would be to get to a point where all that was left in VB6 was a shell calling all the .NET stuff; at that point you write the shell in .NET and you're done.

Sounds easy, doesn't it?  I should point out that I've never actually done it.  <g>  But if I were facing your task, that's how I'd go about it.  The place to start would be with some piddly little VB6 app with a few classes and such; once you have success with that, start moving to bigger things.
Kyralessa Send private email
Wednesday, December 06, 2006
 
 
If you have to work with COM objects in .Net, then use VB.Net and not C# because VB.Net automates some things that C# does not and your life will be much easier.

VB.Net also has some other productivity enhancements that C# doesn't have, like Optional arguments for procedures and automatic event binding.
Wayne B Send private email
Thursday, December 07, 2006
 
 
"Where are we?  Near Seattle.  Because of time differences I doubt working with a European consultant would work."

Barring the distance factor, I'd like to offer my services more as a 2nd tier consultant so to speak (like Mike Green in the UK offered, except I'm from Malaysia). I have 24 years+ experience in VB (around 4-5 years in VB6) and have been working in VB since Quick Basic 4.5. I am gradually learning VB.NET and ASP.NET but I could help you on the VB6 side.

Why not use this forum as a "2nd tier consultant" whilst hiring local consultants so as least you can be guided as to the general direction take. There are many expert programmers on this forum and some who are very good in VB6 and VB.NET / ASP.NET 2.0 which you could take advantage of by posting  your issues...
Ezani Send private email
Tuesday, December 12, 2006
 
 
We have a similar situation over here that I am weeding through right now.

I agree with Kyralessa and I completely disagree with anyone who is advocating porting the whole code base into .NET.  That's just crazy talk.

I like the idea of replacing chunks of the VB app with .NET as new functions are needed. I added a plug-in architecture to an old VB app.  All the plug-ins are in .NET and are show up dynamically in the VB app.  I've had no interop problems except for some hiccups registering the assemblies on the target machines.

Here's a link to an interop toolkit for doing just this:
 http://msdn2.microsoft.com/en-us/vbasic/aa701259.aspx

-Scott
Scott Penner Send private email
Thursday, December 14, 2006
 
 
Before you start, remember that you'll need to email all your customers explaining that the next release of the software will take over a year, will have no new features, will have new bugs, will be slower, and will be harder to download and install.

If you're really customer focussed, you could refer them to a competitor who doesn't make insane business decisions based on the advice of programmers who are trying to improve their CVs by using the latest dev tools.
Me me
Monday, December 18, 2006
 
 
Common me me, don't beat around the bush.

Tell us all how you really feel :-D
Scott Penner Send private email
Tuesday, December 19, 2006
 
 
I'd have to agree with me me. I'm still feeling the pain of what Microsoft did to VB6 by going .NET. In fact, Kyralessa's method illustrates it perfectly. You're rewriting the SAME function except in VB.NET code. There is really no advance here - the keyword is REWRITING. When what one should really be doing is capitalizing on what one have already invested one's time and knowledge in (for me, it's 24 years up to VB6) to do NEW things as technology progresses such as doing mobile apps in VB6.

Just try to imagine if Microsoft had not thought of .NET in the first place. VB6 would go to VB7 with new features us VB programmers would be comfortable with (probably embedded VB3.0 would be absorbed into VB6) and Visual C++ would still be going strong and both would be gearing up for 64-bit programming and new GUI features of Vista would be incorporated into the RAD tools.

There's too much headaches and hiccups in .NET. I've given it a go and experienced it up to the point that I'm forced to do .NET programming just because customers want "the latest technologies" but don't know what that means. I mean "being able to write an app in different languages aka Visual C#, Visual Basic.NET, VIsual Java.NET doesn't make sense A VB programmer would still continue with VB, why would he or she want to use another language unless that language offers what VB6 cannot.

MSIL is like trying to make VB6 programmers into C++ coders and downsizing C++ coders into VB6 coders (see some of the C++ rants on the Joel on Software forum : VC++6.0 or VC2005).

.NET doesn't cut it because there's too much loss of productivity by programmers RELEARNING rather than MOVING FORWARD with what they already know to do the latest things!
Ezani Send private email
Monday, December 25, 2006
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz