3

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

MarkJ
  • 30,070
  • 5
  • 68
  • 111
w0051977
  • 15,099
  • 32
  • 152
  • 329

3 Answers3

2

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.

IAbstract
  • 19,551
  • 15
  • 98
  • 146
  • Thanks for this + 1. I am the sole developer of the app in question. I am from a .NET background and have more experience with .NET than VB6 (I don't like VB6). Performance and overhead are my main concerns. If there is one call to the interopability layer, then I suppose the overhead would be low. – w0051977 Jul 04 '12 at 19:41
  • You say:"If you know that the application is to be converted fully to .Net". Surely the answer will always be yes i.e. all apps must be converted. – w0051977 Jul 04 '12 at 19:51
  • @w0051977: I would like to think that *all apps must be converted.* It simply depends on the relevance of the application. ;) That can be read as *'If the decision has been made ...'* – IAbstract Jul 04 '12 at 20:23
  • Thanks again. I assume that your suggestion is option 1? – w0051977 Jul 04 '12 at 20:27
  • If backed into a corner ...yes. But that is why I presented pros/cons of each regardless of my personal experiences ...simple facts. – IAbstract Jul 04 '12 at 20:29
  • I agree. Everything has its pros and cons. I think option 1 is right for me. – w0051977 Jul 04 '12 at 20:31
  • 1
    We are using approach 1 using RegFree Com at the moment and it works very well. The codebase is 95% VB6 still though. No idea what will happen as the migration progresses. – Dabblernl Jul 05 '12 at 08:44
0

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.

Community
  • 1
  • 1
Mark Hall
  • 53,938
  • 9
  • 94
  • 111
  • 1
    Thanks. I don't understand what you mean by: "you are under time constraints". – w0051977 Jul 04 '12 at 18:41
  • @w0051977 you said you didn't have the time to do it, thats a time contraint to me. – Mark Hall Jul 04 '12 at 18:43
  • I see. Do you ever develop your application or do you just support it? – w0051977 Jul 04 '12 at 18:44
  • @w0051977 right now this application is in maintenance mode. We have current applications written in .Net but without all of the features of the VB6 application. So... I am going to have to bite the bullet and redo probably this year. – Mark Hall Jul 04 '12 at 18:47
0

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.

jjb
  • 1,340
  • 1
  • 13
  • 21
  • Which tools to migrate? Microsoft withdrew their tool in 2010. Code Architects and Artinsoft are still developing their tools AFAIK. – MarkJ Jul 04 '12 at 21:19
  • @MarkJ That's who I meant. Artinsoft and vbmigration partner produce competing products and I would say that both are improving, certainly they claim to be. VBmigration partner now targets c# also as artinsoft has for a while. Otherwise people can target vb2008 for their conversion using the migration wizard to do a lot of the work. – jjb Jul 06 '12 at 21:48