Less time consuming : Rewriting or converting an app from VB5 to C#

Question

I've got a contract where I have to continue the development of and old application suite that was programmed in VB5 back in the days.

I've bug to fix and new feature to develop.

So I have a few choices:

1. Keep programming in VB5 (NOOOOOOOOOOOOOOO!!!!)
2. Convert VB5 to C# (How??? Is it possible without going insane?)
3. Rewrite the whole application suite (Very time consuming)

Is there any other choices? What should I do?

EDIT: Ah and also, it relies on an ACCESS database which I'd like to move to SQL EXPRESS. Because it's a crazy database made illogically by a stupid programmer from the '90s lol.

Thanks

Answer 1

Maybe you should first convert to vb.net, and then to C#?

Answer 2

The choice I've made every time is to just re-write, or purchase a suitable replacement if I could find one.

I have tried doing incremental upgrades from VB6 to VB.NET, but I don't like that approach because it leaves around ActiveX controls that I'd rather not use. Re-writing is cleaner.

I don't think there is a converter from VB5 to C#. You might be able to go from VB5 to VB.NET and then convert to C#, but in my experience it's less time-consuming to re-write than it is to try to upgrade and fiddle around with the broken code.

Answer 3

There is no reliable way to do 2) so it's 1) or 3).

And I don't think your customer wants to pay for 3). But maybe you can sell it on reliability, support etc.

Otherwise you're stuck with 1)

Answer 4

One approach would be to tactically rewrite sections of the code in C# - you could start with the areas you are likely to be bugfixing the most, create C# assemblies to mirror the functionality, and then expose these to the VB5 code through COM interop.

A good suite of Unit Tests would be highly recommended for this approach!

I've heard that Working Effectively With Legacy Code by Michael Feathers is the best book around for understanding how best to chop up a problem like this.

Answer 5

The answer definitely depends on a lot of factors. I recently had a similar project (a 10-year plus old VB6 Windows app with a large, spaghetti codebase), and addressed it with a "hybrid" approach:

• Bugs were fixed in VB6
• New features were developed in .NET 4, using COM interop

We developed some WPF dialogs and styled them to go with the old interface to handle new UI.

This option only works when the new features are fairly independent of the main app, but it has the advantage of at least taking advantage of the productivity of new technologies and also paving the way for future conversion.

Answer 6

If you just need to fix a bug, and it's a reasonably simple bug, and you don't anticipate much more work beyond that - stick with VB5. Anything else will introduce far more work.

However, if this is really a "live" product which you expect to work on a lot in the future, I would probably start from scratch. My guess is that you've learned a lot about design and architecture since writing the app - so you might as well take the opportunity to write a more maintainable app. (You'll also probably have learned which design decisions in the original app ended up being mistakes.)

Answer 7

I've recently finished working on a project where we converted a lot of legacy VB6 applications to C# using Artinsoft's VB Upgrade Companion.

It's a tough call to decide which approach is the best. In a lot of cases, converting the code can end up being very painful, especially if there is a lot of logic based around features which are significantly different between the two platforms (e.g. one-indexed arrays, or handling errors via the Information.Err object instead of through exceptions).

On the other hand, if you try to write it from scratch, there is a good chance that you'll accidentally change some subtle behaviour that isn't immediately obvious when reviewing the original VB5 code. Things like this can be difficult to track down.

A good compromise is to use a converter to port the code over, then use this as a guide for writing things from scratch, as there will hopefully be places where you can just lift converted code across straight into the new code base. At the same time though, you get the benefit of writing more maintainable code everywhere else.

With all that said, if the original VB5 is well written and (relatively) well architected, then I would recommend against any sort of upgrade. You will spend far more time trying to match the existing behaviour of the old application than you would just working on the old code.

Good luck with whatever you decide to do - you'll need it :)