Results 1 to 4 of 4

Thread: Migrating My application from VB 6.0 to VB.NET 2015

  1. #1

    Thread Starter
    Registered User
    Join Date
    Jan 2018

    Migrating My application from VB 6.0 to VB.NET 2015

    Hi Team,
    Good Day...

    We are planning to upgrade our Windows based application coding from Visual Basic 6.0 to VB.NET 2015.
    Is it possible to upgrade Visual Basic 6.0 to VB.NET 4.6 directly without going step by step like VB 6.0 to .Net 2.0 ----> .Net 2.0 to .Net 3.0 ---> Net 3.0 to .Net 3.5 ---> .Net 3.5 to .Net 4.0 ----> .Net 4.0 to .Net 4.5..?

    Our Windows based application is developed in Windows XP both components "Farpoint Input pro V2.0 and Farpoint Spread V2.5 " and those are few webservices we are using for downstream application. So we are currently using Visual Basic 6.0 and .Net Framework 1.1 for compiling the code and create the new package in Windows 2000 server.

    Our plan is upgrading the code Visual Basic 6.0 to .Net Framework 4.6/4.7 (VS 2015/2017).

    My Question are her
    1. Is it easy to upgrade the VB 6.0 to .NET 4.6 with VBUC tool?
    2. Do we need to rewrite the whole code from Scratch?
    3. When we open the coding in Windows 7 64 bit We got errors like some .OCX files are missing.., Is These .OCX, .Dll files are missing because of old version FarPoint spread thirdparty software?

    Can you help me on above questions is greatly appreciated .

    Thank you so much in Advance.

  2. #2
    Super Moderator si_the_geek's Avatar
    Join Date
    Jul 2002
    Bristol, UK

    Re: Migrating My application from VB 6.0 to VB.NET 2015

    Welcome to VBForums

    1. I assume you are referring to the Visual Basic Upgrade Companion, which I don't have experience of... but as it seems to be free (up to a certain size) you can try it out. I would be surprised if it gives perfect results, but it should at least make the process much simpler.

    2. You probably don't need to (lots can be copied+pasted, and a conversion tool should get things working), but in the long term it would be best to rewrite several things (especially things like database code, as that has changed significantly).

    3. If you have installed them then you may have installed the "wrong" one for your code, for example a 32-bit project (including all VB6 projects) will only be able to see 32-bit OCX's, not any 64-bit ones (and a 64-bit project will not see any 32-bit ones). With .Net projects you can decide whether the project is 32-bit or 64-bit.

  3. #3
    Super Moderator Shaggy Hiker's Avatar
    Join Date
    Aug 2002

    Re: Migrating My application from VB 6.0 to VB.NET 2015

    There was an upgrade tool included up through VS2008. It did such a mediocre job that people generally recommended rewriting from scratch rather than using that tool. VBUC looks like a different/better solution, so it's worth a try. However, VB6 lacked a whole lot of things that .NET has. Most of that can largely be ignored. For example, VB6 didn't really do threading, though there were ways to make that work. Since VB6 generally didn't do threading, an application written in VB6 usually worked well with just a single thread, so it would work just as well in .NET in a single thread. Whether there would be some advantage gained by using multithreading for some part of it is a decision that can be made later or not at all.

    Where VB6 and .NET differ most is in classes and generics. You may not gain any advantage from taking a working VB6 application and redesigning it as more class based, but it would likely be a significant difference. Generics, on the other hand, were introduced with 2005 (framework 2.0) and added some significant advantages. If you have a bunch of arrays, then that's an area where doing some updating would likely improve things. Arrays exist in .NET, but you also have the List(of T), which gives you what amounts to an array with methods to Add, Insert, Remove, and so forth. Those are some nice features that greatly improve on Redim Preserve, which was all you had that did anything like that in VB6. You also have the Dictionary class, which allows for faster lookups than an array seek, and gives you what amounts to an array with indexes that aren't necessarily integers. So, with generics, there was introduced some features that allowed you to write more efficient and more convenient code. You can still use arrays, and still use them EXACTLY as you did in VB6, but that's an area where you may want to consider improving.
    My usual boring signature: Nothing

  4. #4
    You don't want to know.
    Join Date
    Aug 2010

    Re: Migrating My application from VB 6.0 to VB.NET 2015

    It's always kind of hard to answer these.

    The conversion tool works best for very simple VB6 projects that follow the practices Microsoft predicted. Even then, the results can be a little weird for maintenance going forwards.

    Think about it like you've got a book in English, and you want it to be in Spanish. If you paste the text into Google Translate, you'll get results that work. But there's a reason we pay people for localization work. Imagine if you were making a The Simpsons reference, so a character says, "Eat my shorts". That phrase isn't meant to be taken literal in English, it's a statement of disrespect. But Google Translate doesn't know that, so it might spit out Spanish that reads, "Consume my pants." That's "the same thing", but it's very likely a Spanish reader won't get it. That's what the conversion tool does most of the time. It spits out VB .NET code that does the same thing as the original, but won't be as familiar or sensible to a VB .NET developer.

    I can't tell you what that even looks like, because every project is different. You should be able to make a lot of money making a career just out of these kind of ports. But you can't, really, because no one believes it's as hard as it is or costs as much as it should. That's why they sat on it without paying a developer to maintain it for 15 years.

    That you're using third-party components will be the most difficult part. Microsoft didn't know anything about those components when writing the conversion tool. You'll have to figure out if those components still work in modern Windows (Windows 7 isn't "modern", only Windows 8.1 and 10 are supported). You'll have to figure out how to install them if they are. You'll have to figure out if VB .NET can interface with them. And you might have to rewrite the parts of the program that use them if the conversion tool can't make sense of it.

    So the only real advice is to give it a try and see how well it goes, but be prepared to have to pore over the code and redo some parts of it. Do you have an automated acceptance test suite? That'll be really handy for proving the conversion didn't break anything.
    This answer is wrong. You should be using TableAdapter and Dictionaries instead.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts


Click Here to Expand Forum to Full Width