Stop using VB6?

Question

I am developing a VB6 legacy application. I have started writing all new code in VB.NET essentially creating what I am calling an interoperability layer. I could approach this in two ways:

1. Write all new code in VB.NET using this interoperability layer and use a phased approach to upgrading.
2. Continue writing VB6 code and then convert it all at a later date (use a big bang approach). I do not have time to convert the entire application at the moment.

My question is, which is the better approach?

UPDATE The reason I favour option 1 is because there is an ASP.NET application. The previous developer would effectively duplicate code in both apps i.e. VB6 and ASP.NET. Therefore some of the code in the ASP.NET app can be shared with VB6 and vice versa. That is why I believe option 1 is better, but I cannot find any literature to suggest that developers actually do this

Answer 1

In a previous life I was involved in the same type of project. The original application was written with Access as it's framework. Then came VB6 which seemed to work nicely and allowed for more features without having to alter much of what was written originally in Access.

Along came .Net ...

...as much as I disliked the developmental staging to .Net and being forced to work with an interoperability layer it was necessary.

That said, I will answer the question as subjectively as possible:

If you know that the application is to be converted fully to .Net, then do as much of your new development with .Net as you can. There is no reason I can think of to put it off other than the perceptions (and truths) about interoperability - e.g. more overhead, performance, etc.

sidebar - at least you don't have interoperability issues with Access ...when it crashes, it brings down everything. It was my first experience with interop (with Access) and it wasn't pretty.

Advantages to waiting on .Net development:

1. shorter time to deliverable (no interoperability layer)
2. more stable app (no interoperability layer)

Disadvantages to waiting on .Net development:

1. Long (and likely unprofitable) release cycle while the entire app is re-written
2. Lots of new bugs introduced
3. Learning to write unit tests when that will be the last thing on your mind

Beginning .Net development now will increase your chances of success in the long run. I don't believe an interop layer is going to cause you the headaches it did for me - and any degradation in performance should be minimal.

I don't know if you are involved with a team of developers on this project, but if you are, make sure everyone is on board with the move to .Net. I've seen a few VB6 developers strike a dear in the headlights pose over VB.Net. The nature is to continue writing in the same style they're used to.

Answer 2

I personally would use your first option(since you already have your interoperability layer implemented), that way it will make the rewrite when you do it less painfull.. if you design you class structures correctly. The second option would be my preferred way to go but since you are under time constraints, use the first. Eventually the VB6 runtimes are not going to be part of newer versions of Windows, see this SO question. I myself have a VB6 application that is going to need to converted.

Answer 3

Concentrate on giving the users what they want. If it's easier to accomplish this in vb6, then do that. Worry about converting to vb.net when it's necessary to convert to vb.net. The tools to convert vb6 to .net are now pretty good, are under constant development and so can be expected to improve further.