Should We Be Developing New Apps with VB6 ?

[JoeAtWork]

Like many of you, I have been developing apps in Visual Basic for years (it's just about a decade now).

Also like many of you, I have been moving to .NET. I like .NET, it's full OOP implementation being my favourite feature.

But I still feel I can create apps quicker and more reliable in VB6. This is not anything to do with .NET, it is everything to do with my years of experience with VB.

So the question I pose, am I doing my clients a disservice if I write any new apps in VB6?

For arguments sake, let's say we are not talking about Enterprise apps - in my opinion those should be created with whichever technology will likely be supported the longest.

But for those relatively small stand-alone apps (but are still critical to the business) - am I hurting my customers if I use VB6?

My current new project - a Bill Of Lading database. It's pretty simple, user fills in Customer fields, picks items, saves it, prints it. It will integrate with Quickbooks to create invoices.

It will very likely have modifications in the future, but probably will never expand much beyond the initial requirements.

Let's say it's expected life-span is 5 years. What would you recommend - VB6 or .NET?

Considerations for VB6
- I can build it faster
- it will be very robust because of my experience and standards I've learned over the years
- I expect it would be more efficient, and use less resources
- I worry that during it's lifetime it will need to run on an operating system that won't support VB6 apps
- it's possible they may want future additions that would be harder to implement in VB6

Considerations for .NET
- will be supported in the foreseeable future
- my initial release may not be as robust because there are still techniques in .NET I am not sure of the best practices

Looking forward to your opionions.

 

[dilettante]

I wonder how much the rapid churn in .Net factors into this.

It's difficult to obtain formal training in VS 2005 topics even today (most official Microsoft training is still VS 2003) and 2008 is nearly out. Almost on the heels of that we'll start seeing betas of the next VS release coming out.

While older applications may typically run on newer Frameworks, the huge list of .Net language and CLR features has items deprecated frquently. Will that VB.Net 7.1 application even compile with VB 9? VB 10? Are you up to the steady updating and retesting just to stand still?


VB6 was stable for a long time. Then stagnant. And now surely frozen in the past. This can be an advantage, and sometimes a curse.

I'm not sure the answer is clear cut. It certainly has gotten harder and will continue to get harder yet to stay with VB6 as time moves forward though.


When Visual Foxpro was killed there was at least an add-on pack named Sedna produced. This seems to be new controls and libraries to provide btter support for Vista UI features and such. Of course even Sedna was dumped out into the open source arena and Foxpro development stopped.

Of course VFP9 has mainstream support until 2010 and extended support until 2015, so that community still hasn't been faced with the issues we're looking at.

I doubt there is any plan for a "VFP.Net" so they'll be triply doomed when the boom is lowered: no more VFP, no logical bridge product, and a radical change in the way they handle databases.

 

[harebrain]

Along with the .NET churn factor that dilettante mentioned, you should consider the organization's inertia. Are they bent on migrating to the new OS as soon as it hits the shelves, or are they content to "stick with what we have because it's working."

If they don't jump aboard every fast-moving train that comes along, they probably already have a huge investment in a VB 6 code base. Developing VB 6 one-offs, then, doesn't add much risk.

 

[BobRodes]

<.NET churn factor
I wonder if Microsoft is beginning to have cash flow problems.

 

[DerFarm]

Until MS does something about Vista, I'm not exerting myself to utilizing ANYTHING new. Nothing works under this POS. You have to re-invent the ROCK, much less the wheel.

My guess is that the current iteration of .Net will be totally obsolete when the dust settles on whatever Dell and Gateway decides is the OS of the future.

 

[JoeAtWork]

My understanding is that .Net 3.0 and 3.5 are merely add-ons to 2.0 (i.e. few if any deprecations).

 

[dilettante]

True JoeAtWork, most of the serious churn is now trying to keep up as a developer. At least a 2.0 application ought to run on a machine with 3.5 on it pretty well.

My point was really that as a developer you have little choice but to keep on running. If you don't keep upgrading old source to the new standards it'll get harder and harder to maintain. Lots of old stuff still works, but is deprecated in favor of new ways to do the old things.

It reminds me of ancient times when shops could still run Cobol68 programs though they were programming in Cobol74. After a while people couldn't work on the Cobol68 stuff without a lot of grief. With .Net things change every 2 or 3 years.

Of course Classic VB went through the same thing back when it was still a live product. VB6's stability was a sort of "Golden Age" while it lasted.

 

[MichaelRed]

from the depths of the mud pit, there was (and probably still is) the axiom that MS takes at least three tries to get a workable product line.

Was true of Win, VB, ... ad-naseum

After the third production ver of a product, they still need 'upgrades' (e.g. service packs and new releases) to work out the bugs.

the .net products seem to -just now- be getting to the third version, so, IF history is a reliable guide, the .net framework should be getting to the actually usable stage of development.

However the .net framework id NOT vb.net, it is essientially just one of the ".dll"s which are a part of the overall scheme which needs to include the various language packs. In this 'revision' MS is attempting to integrate the various intrinsic (native/embedded) functions of the several languages into a single? set of routines available to all of the languages with common responses to the seperate 'callling' styles. So, I think the path to stable develpoment in th e .Net arena has at least one new layer of complexity to deal with. For example, if a procedure (call it MyDotXXX just to have a name) is called from vb it can also be called from C#, CPP, FORTRAN, and other languages. So if this is found to be flawed -in C#- the developing team must first determine wheather the error is in how C# calls the procedure, or wheather the common underlying procedure is at fault, or some other area of the interface.

Ti summarize this, I believe that the entire .NET experience should be viewed as the beta test and early learning experience for at least one more round of releases from MS before the general approach should be used for production.




MichaelRed

 

[dilettante]

Well there are some major changes in store after VS 2008.

What the heck is "VBx"?

 

[BobRodes]

I can hardly wait...

 

[dilettante]

Yeah, heh. I see they're considering ditching Mid$() assignments too. No more:

[tt]Mid$(strBuffer, n, m) = strInsertion[/tt]

... along with getting rid of [tt]Erase[/tt] and whatever else they don't like or don't comprehend.