-5

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.

Two approaches I have in mind:

Approach 1:

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.

Approach 2:

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 the various features usable, I am thinking it would be less painful to do the first option. I'd like to know if there are any pros/cons I should be aware of doing it either way though.

casperOne
  • 73,706
  • 19
  • 184
  • 253
Brandon Moore
  • 8,590
  • 15
  • 65
  • 120
  • 4
    Not sure on what merit this has been closed so I will add my comment: I would definitely go with option 2 - you should be moving towards .NET if you are not already so this way you can re-write VB6 features into .NET bit by bit and you will be left with .NET, other way round and you will always have legacy VB6 to convert – Matt Wilko Feb 21 '12 at 16:46
  • 1
    @casperOne Why was this closed? It's a question about which COM<->.Net interop scenario is technically preferable ("less painful"). – MarkJ Feb 21 '12 at 18:10
  • 3
    @MarkJ What is specified in the banner below and what you just said ("preferable") are mutually exclusive? – casperOne Feb 21 '12 at 18:17
  • @casperOne Could you be a little more vague? – Brandon Moore Feb 22 '12 at 08:05
  • 4
    This closing is justified. Any answers to this question will be very biased towards the principles of the user answering, and we want factual answers. – Purag Feb 22 '12 at 08:08
  • 4
    @Purmou I think you're thinking of the Skeptics SE site. This is SO where people are allowed to ask question based on specific programming challenges they are facing and people are allowed to share their EXPERIENCE which need not be backed up with a factual reference to some book or anything like that. – Brandon Moore Feb 22 '12 at 08:13
  • 1
    I answered your meta question in a lot more detail. I hope you see why I agree with casperOne in this case. – Purag Feb 22 '12 at 08:14
  • 7
    Do not use your question body for meta-commentary: if you have an issue, ask a question on MSO, like you [already did](http://meta.stackexchange.com/questions/123069/why-was-this-vb6-migration-question-closed). –  Feb 22 '12 at 09:58
  • @Matt Can you please post that as an answer now that this question has been reopened? I want to post a question as a comment on it but would rather not do it in this mess of comments here. – Brandon Moore Feb 22 '12 at 10:14
  • @MarkTrapp After my question was closed and then quickly re-opened, I feel I have a right to make sure people are aware of this fact before deciding to close so they can at least consider than it's an arguable decision to do so. Please don't edit my question again, but feel free to vote to close it if you feel that's unacceptable. – Brandon Moore Feb 22 '12 at 10:24
  • 2
    @BrandonMoore I see you've rolled back the question to include your mention of the Meta discussion. Please don't do this. If you want to discuss it, do so on Meta, but keep your questions clean. There is no point in dragging it out here. – Bart Feb 22 '12 at 16:08

1 Answers1

1

I would definitely go with option 2:-

You should be moving towards .NET if you are not already so this way you can re-write VB6 features into .NET and when you have migrated everything you will be left with a new .NET app.

The other way round and you will always have a legacy VB6 app to convert at some point.

Matt Wilko
  • 26,994
  • 10
  • 93
  • 143
  • The thing that concerns me about option 2 is that there are certain vital features that I can't port right away and are so tightly coupled to the the forms in the vb6 exe that they're impossible to use through interop. – Brandon Moore Feb 22 '12 at 16:04
  • Also, the idea (if I wasn't clear) was to basically make the Program.cs into something vb6 can call and initiate rather than being initiated directly. This way, it has the primary role but can step back when necessary to let vb6 present certain forms. Otherwise I don't see a practical way to use the vb6 forms that I need (but won't be able to rewrite in the 1st phase). Once everything is ported, then it should be an easy switch to take vb6 out of the equation and start the same module vb6 is calling to from a .net exe. I would like to hear your thoughts in light of that... – Brandon Moore Feb 22 '12 at 18:45