We are about to start a new project using an existing SQL DB, but this project is going to need to reuse a number of core features from an existing vb6 app that uses the same database.

The approach I would like to try:

Have the existing vb6 application be the entry point, but immediately call a .net class to present the main screen and menu. If the user needs to use a feature/form that is in vb6 then raise an event to vb6 to load that form and hide the .net side of it until it's done.

The alternative:

Opposite of the above, create a .net exe to be the entry point and call a vb6 dll whenever I need a vb6 feature/form.

Because of initialization that goes on in the vb6 app that makes various features usable, it would be much less painful for me to try the first approach. Moreover, there is some functionality that is very tightly coupled to the forms in the vb6 app and is vital to the application, but I will not be able to immediately port it to .net in the first phase.

I realize this is not the ideal approach but unfortunately there are real world concerns that make taking the idealistic approach near (if not entirely) impossible.

So my question is: are any specific pitfalls I should be aware of in doing this?

  • 11
    Just FYI, here's another real world concern: All versions of the Visual Basic development environment from 1.0 to 6.0 have been retired and are now unsupported by Microsoft Feb 22, 2012 at 20:38
  • 1
    Why start the new project in .Net if you are not retiring the old code? The code mix will not buy you anything in either of the scenarios you have described.
    – NoChance
    Feb 22, 2012 at 20:49
  • 2
    Probably because the old app is way too large to rewrite the complete application in .net in one step. We are doing the same thing with an old Access application. Feb 22, 2012 at 21:16
  • 1
    @SnOrfus <Sigh> It hasn't been 'supported' for 4 years but here we are. I'm pretty sure taking a year to transition while still being able to sell software is going to be a better choice than taking 6 months off to rewrite the entire thing at once. And either way it's not my decision to make. I'm just trying to figure out the best way to do the job I'm given. Feb 22, 2012 at 22:23
  • @BrandonMoore: I hear you, and don't envy your situation. You've got to cut the cord sometime and I'm just giving you some fodder for the decision makers. Feb 23, 2012 at 4:37

1 Answer 1


I'd say the most viable approach is to use the Strangler Vine method. Martin Fowler does a great job at describing the approach (I also found an article on docstoc that goes into more detail.

Also it's hard to recommend which approach would work best for you, but I've always found that hosting VB forms in .NET is easier than the reverse.

  • Thanks, and thanks for the links. One thing I think I have not been able to clearly communicate here is that I would not be hosting .net forms in vb6 'either' way I go. I will try to update with a code example of what I'm thinking later when I have a chance though. Feb 22, 2012 at 22:35
  • i.e. Vb6 would call out to an interop .net class that would in essence be a modified version of what would otherwise be the usual Program.cs. This modified Program.cs could just as well be called from a .net exe though which is what ultimately would happen when vb6 is phased out. But in the interim since vb6 is at the base, I could hide the .net side and let vb6 present its own forms when necessary. Hopefully that is a clearer explanation of what I'm pondering. Feb 22, 2012 at 22:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.