Migrating vb6 application to .net using microsoft interop?

Question

1.00/5 (2 votes)

See more:

We are planning to migrate our application from VB6 to .NET. We want to migrate the project part by part in an iterative faction. For migrating the application we are use Microsoft interop (COM Wrapper).
My question is have any one used it,
1) Do anyone came across any challenges while migrating the application using ?
2) Will using interop(COM Wrapper) there is any degrade in application performance? 3) Is there is any other disadvantages of using Microsoft interop(COM Wrapper)?

Here is more details about the approach.

Current architecture
• VB6 desktop application and interacts with different databases
• This application has few DLL’s which has the core business logic

Proposed architecture
• Use ARTINSOFT tool and convert the Core logic VB6 source code to .NET in piece by piece manner
• Move the converted core business logic .NET source code to a Web server and host them as Web services
• Use the existing VB6 forms and communicate to .NET source code using INTEROP

What I have tried:

We have already done the proof of concept, but we are looking for more inputs.

Posted 27-Feb-16 13:43pm

AjayRRathi

Updated 29-Feb-16 6:25am

v5

Add a Solution

Comments

Garth J Lancaster 27-Feb-16 23:19pm

I dont think you've explained enough about what your VB6 project does/contains, or what/how you will handle "For migrating the application we are planning to use Microsoft interop". Do you really mean 'COM Interop' or ?? is another question I'd ask.

Performance ? take for example - you have a self contained unit of code in VB6 that does x, that requires a number parameters - thats a different premise from having a unit of code in VB6 that you're calling continually with massive amounts of data - my thoughts are here that marshalling the data could be one issue you'd face - Maybe only you can answer the performance issues by adding a performance measuring layer to each (old, new) units of code and monitoring it yourselves, and if its 'less than desirable' by whatever measure you use, you may need to re-write the unit

That you've done a proof of concept is great, but, thats your best way to look at performance - not someone elses 'when I do x on my machine I measure this' - it has to be relevant to your organisation

Kenneth Haugland 28-Feb-16 1:17am

I would switch for reasons that you don't mention, maintainability. VB6 is hopelessly old, kids won't know how to use it nowadays.

ZurdoDev 29-Feb-16 11:50am

You are not re-writing the code? You're just wrapping it in a COM wrapper? That sounds like a bad idea. I'd suggest taking the time to re-write the code.

AjayRRathi 29-Feb-16 12:14pm

Thanks RyanDev. We are rewriting the code. The plan is to do it in iterative way. We are planning to we will slice the application in piece and convert it piece by piece. We are using the COM classes to generate the wrapper on every piece that we have converted to .NET. Once we completed whole application we will remove the wrapper classes and the complete application will be migrated to .NET. Let me know your views.

Sergey Alexandrovich Kryukov 29-Feb-16 17:20pm

Microsoft COM interop is one big disadvantage, and using interop at all (DLLImport) is just the smaller disadvantage. It is acceptable only is using some platform-specific products (usually, it could be 3-rd party ones, especially related to some non-standard hardware).

And finally, having any trace of VB6 is not even disadvantage, its a total disaster. This product was already badly, impossibly obsolete even when it first appeared on market in 1998. The way you plan to "migrate" would not be migration at all. If you leave any trace of VB6, you just add new disaster to existing disaster. The only thing to to is to write it all in .NET, without using anything not based on .NET FCL.

—SA

AjayRRathi 1-Mar-16 10:13am

Thanks Sergey for our time. we are not planning to us DLLImport. Please find the below link, which explain how can we create a COM wrapper to call .NET Code in VB.
http://www.codeproject.com/Articles/18939/C-Com
What we are planning is convert a part of project. Use the converted part with VB6. continue the same approach till the we migrate complete project. Once we are done remove the COM classes that we added to call the .NET code in VB.
This way in the end we will left only with .NET code. And complete VB6 code will be migrated.
Let me know your views on this.

Sergey Alexandrovich Kryukov 1-Mar-16 10:25am

I already did. I'm afraid you can waste too much time. If you simply write new project from scratch (say, using your old code as a kind of document), your just write code. If you "convert part", you still have to write the same amount of code, plus a lot of temporary code, plus a lot of effort to resolve all problems with old code, interop, and so on. Just think about it.
—SA

AjayRRathi 1-Mar-16 11:43am

Thanks Sergey. It is helpful.

Sergey Alexandrovich Kryukov 1-Mar-16 14:46pm

You are very welcome.
—SA

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)