Click here to Skip to main content
15,936,821 members
Please Sign up or sign in to vote.
1.00/5 (1 vote)
See more:
Hi,

I have a fairly large application, written in VB6.
I want to convert it to Vb.Net using Interop, but do not know how to do it.

The application is so big that I really can't re-write it in VB.Net.

Thanks and best regards,
Furqan
Posted
Updated 23-Mar-11 6:53am
v2
Comments
Dalek Dave 23-Mar-11 12:54pm    
Edited for Readability.

There are several tools available to do this for you. Writing the converter yourself more likely takes more time that rewrite the application itself. Google for example "convert vb6 to vb.net" and you'll get results like:
- http://www.visualwebgui.com/Gizmox/Landing/tabid/674/articleType/ArticleView/articleId/909/SaaS-Web-Cloud-and-Mobile-enablement-of-your-VB6-application.aspx?gclid=CPOb8JmT5acCFYZH3godimrcNw[^]

- http://www.artinsoft.com/pr_vbcompanion.aspx?gclid=CKTEy5qT5acCFYGCDgodYUbLTA[^]

- http://www.vbmigration.com/[^]
 
Share this answer
 
Comments
Dalek Dave 23-Mar-11 13:06pm    
It is still a lengthy and time consuming task.
Wendelius 23-Mar-11 13:34pm    
Indeed it is, but still much less time consuming than writing a custom converter (or as you said biting the bullet :) )
Sergey Alexandrovich Kryukov 23-Mar-11 19:46pm    
5 for the effort, but I think IRL Dalek is right. Re-writing the code only seems more difficult, but using "converters" can do more harm than good, due to broken hopes.
--SA
Wendelius 24-Mar-11 1:59am    
It's possible. I've heard of very successful projects were converters were used but guess that it depends on the code and UI complexity in the VB6 version.
Sergey Alexandrovich Kryukov 24-Mar-11 2:02am    
Maybe, but I know the negative results, too. If UI is isolated from universal and application-specific functionality is one thing, bu how many VB developers do that. So...
--SA
There are vb6 to vb.net converters.
They cost money and are not entirely reliable.

For several years now Microsoft have been telling people "We no longer support VB6", so even their converter is no longer available.

You will have to bite the bullet I'm afraid, and start from scratch on a manual rewrite of the VB.Net code.
 
Share this answer
 
Comments
AspDotNetDev 23-Mar-11 13:29pm    
I think the OP needs to clarify what they mean by "convert", but I don't think they are talking about a code converter. They mention interop. Using interop one can create a VB.net application and call VB6 code. One can also integrate VB6 controls into VB.Net forms using a form of interop, so one can indeed "convert" apps without actually updating the main code base.
Sergey Alexandrovich Kryukov 23-Mar-11 19:44pm    
I think you are right. It's so illiterate to use the word "convert", it looks epidemic here at CodeProject. The alternative would be P/Invoke, but as I understand, VB is not capable of DLL export as wee. VB was a broken development took at the moment of its creation, Microsoft people try to do what it take to phase it out -- for a good reason.

So, ultimately, what Dalek advises is the best. +5.
--SA
You can use the Interop Forms Toolkit to use VB.Net controls from your existing VB6 application. You can also use VB6 controls in your VB.Net application. It may also be of use to you to call a VB.Net DLL from VB6. Again, you can do the reverse and call VB6 code from VB.Net.

Those links should allow you to migrate slowly to VB.Net. The others have already covered how you can convert VB6 code to VB.Net code. By combining Interop Forms, code interop, and code conversion, you should be able to migrate even the largest applications to VB.Net over time while seeing results immediately.
 
Share this answer
 
Comments
Sergey Alexandrovich Kryukov 23-Mar-11 19:47pm    
Oh, I see what you mean. A 5, but I'm still skeptical. I advice to be a realist and follow Dalek's advice.
--SA
Suppose you had to move a very large amount of data from one database to another. And lets make it interesting: although the general conceptual data model and details must be carefully preserved, some of the old data is somewhat dirty, and it is in a different form and structure from the desired database: different tables, different fields, different constraints etc. Now suppose someone tells you: "It is impossible to convert the data using tools, you will have to reenter it all by hand!". I suspect you would think they were a bit crazy (or getting paid by the hour to reenter the data). You would not do a data conversion by hand, right? You would analyze the source and target data models, build a conversion process and test it carefully. You would very likely build and test several versions of the conversion process until you were certain the results were both faithful to the original data and conformant to the specifications of the new data model.
I admit, this is an extreme analogy, but the reality of large software conversion is that tools and automation are extremely useful because they let you fully leverage the legacy codes.

Face it: the source code is the an extremely accurate, formal, and complete specification of what the system does and how it does it. 99% of the time the source is the only detailed specification available. Doing a rewrite from scratch means ignoring the existing source and it means the team will have to rebuild a mountain of functional and micro-level technical requirements manually. Functional requirements gathering will end up taking the majority of your resources. Or does "from scratch" mean reading and recoding 100s of thousands of lines of VB code? That is a recipe for failure. This is certainly NOT where you want to spend most of your migration project budget. Leveraging tools to help you do the job, particularly when facing huge systems, allows the team to spend their resources more effectively.

Both tool-assisted and manual migrations demand a lot of analysis and design work to define how you will effectively take advantage of .NET. The difference is in how you spend the rest of the migration project resources. With a manual rewrite from scratch, you will spend most of your resources re-gathering functional requirements, manually typing in code, and fixing the defects that come along with massive amounts of new manual effort. With a tool-assisted rewrite, you will spend more time evaluating technical redesign options and tuning the translation tool to produce codes that faithfully reproduce the results and behavior of the original application while fitting into the design. I am not suggesting a tool will produce 'perfect' codes right out of the box -- people do not write perfect code manually on the first try either. I also am not saying that all new code should start from a translation; of course select parts of the new system will be redone from scratch. What I am saying is contemporary software analysis and reengineering tools will help you plan and ultimately implement an efficient conversion process that balances manual and automated work to deliver a higher quality result more efficiently.

A detailed discussion of this topic is here:http://www.greatmigrations.com/resources_articles.aspx[^]
 
Share this answer
 
v4

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



CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900