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:
- Write all new code in VB.NET using this interoperability layer and use a phased approach to upgrading.
- 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
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:
Disadvantages to waiting on .Net development:
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.