DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Page 2 of 2 FirstFirst 12
Results 16 to 23 of 23

Thread: conversion from vb6 to vb.net 2005

  1. #16
    Join Date
    Apr 2007
    Location
    Sterling Heights, Michigan
    Posts
    8,663
    Quote Originally Posted by SteN
    vb migration partner looks promising.

    Has anyone tried VBTo (http://www.vbto.net) ?
    Actually, until you posted, I'd not heard of it.

    Have you tried it?

  2. #17
    Join Date
    May 2004
    Posts
    6
    No I haven't tried it either.

    I was just looking around for a converter.

    I appreciate the point about re-writing the applications from scratch and tend to favour this approach myself, but we have several fairly large VB6 applications (50-60,000 lines each) and it is a daunting task to start them all again.

  3. #18
    Join Date
    Apr 2007
    Location
    Sterling Heights, Michigan
    Posts
    8,663
    Quote Originally Posted by SteN
    but we have several fairly large VB6 applications (50-60,000 lines each) and it is a daunting task to start them all again.
    I can certainly understand, and appreciate, that.

    If you do decide to go with a converter, I would suggest testing the ever lovin' bejesus out of the app before actually rolling it out. I suspect you would need to do some rewriting, even with the converter.

    In addition, if you do go the converer route, I would like to hear back from you with respect to what kind of experience, good or bad, you had with it.

  4. #19
    Join Date
    Dec 2007
    Posts
    12
    I have googled vbto and come up with loads of hits but have yet to come across one from someone who has used the product.

    I find download sites a pain in this sort of situation. The typical download site page will mention pretty much every keyword you use in your search

  5. #20
    Join Date
    Apr 2007
    Location
    Sterling Heights, Michigan
    Posts
    8,663
    Quote Originally Posted by delphied
    I have googled vbto and come up with loads of hits but have yet to come across one from someone who has used the product.
    Someone has to be first.

  6. #21
    Join Date
    Feb 2004
    Location
    Longueuil, Québec
    Posts
    577
    The worst problem, when converting, is that a VB.NET application is not structured the same way as a VB6 application.

    Just one example, which, I think, illustrates that very well.

    When does a VB6 application stops? When the LAST form is unloaded from memory

    When does a VB.NET application stops? When the FIRST form, when the startup form is closed.

    In VB.NET, if you set a splash screen as the startup form, the application closes when the splash screen is closed. The application should thus be started in a special way in order to continue working after the splash screen.

    This is the kind of problem no converter can handle, because it is not dependant on the code, but on the flow of the execution.

    If your VB6 applications were written with a lot of ActiveX dll, rewrite the interface in VB.NET and link it to the old dlls, which works usually well, unless you have properties or parameters that are of the Variant type. Keep the old stuff in VB6, develop the new stuff in .NET.

    As a VB instructor and consultant, I have witnessed a lot of conversions. Except for those were only the interface had to be converted, they have all been a flop. Programmers lost days and weeks trying to get a proper conversion before scrapping all that time and eiher stay completely in VB6 or rewrite completely in VB.NET.

    If you are crazy enough to spend 3 months to make a conversion work with a loss of performance compare to the VB6 application, while a 2 months rewrite would do the job and give you something that easier to maintain, go ahead.
    Jacques Bourgeois
    JBFI
    http://www3.sympatico.ca/jbfi/homeus.htm

  7. #22
    Join Date
    Apr 2007
    Location
    Sterling Heights, Michigan
    Posts
    8,663
    Quote Originally Posted by JBourgeois
    If you are crazy enough to spend 3 months to make a conversion work with a loss of performance compare to the VB6 application, while a 2 months rewrite would do the job and give you something that easier to maintain, go ahead.
    Thank you and amen!

  8. #23
    Join Date
    Feb 2008
    Posts
    1
    Being the author of VB Migration Partner, I think I can add some useful hints to the discussion.

    I believe that the confusion about automatic code translators raises because most people expect that they work magically without any human intervention. Alas, this is the approach used by the Upgrade Wizard inside VS and this explains why it performs so poorly. In most real-world cases you can't simply run the tool on a piece of contorted VB6 code and have fully working VB.NET code at the first attempt. Instead, a real-world migration process is an iterative task.

    A code translator should migrate your code according to *your* personal style and preferences. VB Migration Partner allows this by means of so-called "migration pragmas", which are special remarks that you embed in the original VB6 code. For example, this pragma tells VBMP that special code must be emitted so that the VB.NET can correctly handle default members even in late-bound mode (which is one of the main limitations of Upgrade Wizard):
    '## project: DefaultMemberSupport True
    VBMP supports 50+ different pragmas to automate virtually every adjustment that might be needed after an initial quick-and-dirty migration. Pragmas are essential because they allow you to repeat the migration many times and still keep the VB6 and VB.NET code in sync, even if the migration process takes months.

    Quote Originally Posted by JBourgeois
    This is the kind of problem no converter can handle, because it is not dependant on the code, but on the flow of the execution.
    It might surprise you that VB Migration Partner can handle this issue quite nicely. In most cases it can do it without human assistance, in the worst case it requires that you add a pragma. And the same holds true for many other issues, including some that are much more complex than this one.

    Quote Originally Posted by JBourgeois
    If you are crazy enough to spend 3 months to make a conversion work with a loss of performance compare to the VB6 application, while a 2 months rewrite would do the job and give you something that easier to maintain, go ahead.
    With small projects this approach can make sense, provided that you can afford the extra time/cost and that you have a team that is adequately skilled in both VB6 and VB.NET. We at Code Architects are tackling one "monster" app with about 10 million lines; the customer has estimated that it would take about 20 years/man to rewrite it from scratch, which they can't afford. They also estimated that VB Migration Partner will cut cost and time-to-market by at least 70-75%, which made their choice obvious.

    The real value of a good converter such as ours is that an individual developer (or a team) can handle the migration process even if they aren't expert in either the source or the target language. VB Migration Partner contains a huge database of "good programming" rules as well as "obscure bugs" that are unknown to most developers, including a few expert ones. Let me make one simple example:

    Dim buffer As String
    buffer = Space(256)
    ' GetSystemDirectory API returns the number of chars in the result string
    buffer = Left(buffer, GetSystemDirectory(buffer, 256))

    This code works well in VB6 but delivers bogus results when translated as-is to VB.NET. VB Migration Partner correctly points to the issue and its solution. The question is: How many VB developers are aware of this subtle difference between the two languages? You might object that this code isn't representative of good VB programming, yet there are tons of code like it out there, and most "human converter" aren't skilled enough to find and fix it. (Not surprisingly, it took hours to track down the problem the first time we bumped into it.)

    Let me make one more example. In VB6 the default parameter passing mechanism is ByRef, which means that most methods take a byref argument only because the original developer forgot to add an explicit ByVal keyword. The problem is, VB.NET should use ByVal whenever possible because this coding style prevents a lot of compile and runtime errors. (For example, you can have problems when passing an ADODB object to a byref parameter, and there are many other similar cases)

    A developer doing the port or the rewrite, therefore, should carefully check each byref parameter and see whether it can be converted into ByVal without changing the code behavior, but this task takes days on a real-world app, because you'd have to check whether *each* parameter is modified, or passed to a method that modifies it, and so on recursively. VB Migration Partner does it automatically in a matter of seconds, emits a warning, and can optionally convert the ByRef into ByVal for you.

    The code analysis engine in VB Migration Partner can do many other interesting things, including removing unused methods, Declare, and Const statements; replace Exit Function with Return, merge DIM and assignments (eg Dim x As Integer = 1), suggest when a StringBuilder object could replace a set of concatenations, and so forth. Once again, all refactoring actions are optional and can be controlled via pragmas. An average developer can surely perform these task manually, but in practice it happens quite seldom.

    I could continue with more examples of how an automatic code converter can do a better job than developers. Not in all cases, but in a large percentage at least. If you are interested, you can find all docs, KB articles, videos, and code samples at www.vbmigration.com. (We provide both the original VB6 code and the resulting VB.NET code.)

    As far as I know, we are the only migration tool authors who dare to expose all this information to the public *before* they purchase the product. I hope potential customers or just programmers who are curious about conversion technology will appreciate this "transparency" policy.

    Francesco Balena
    Code Architects Srl
    Last edited by fbalena; 02-21-2008 at 02:44 PM.

Similar Threads

  1. Replies: 0
    Last Post: 09-26-2006, 01:41 PM
  2. Speaking of strings...
    By Harlow in forum .NET
    Replies: 246
    Last Post: 10-26-2002, 12:30 AM
  3. VB6 Calling a VB.Net Dll
    By Graham Russell in forum VB Classic
    Replies: 1
    Last Post: 09-25-2002, 08:13 AM
  4. vb.net vs vb6 question...
    By Duane Percox in forum .NET
    Replies: 20
    Last Post: 01-17-2002, 04:50 PM
  5. VB.NET: 3 points of view
    By David Kroll in forum .NET
    Replies: 33
    Last Post: 02-13-2001, 11:23 PM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
HTML5 Development Center
 
 
FAQ
Latest Articles
Java
.NET
XML
Database
Enterprise
Questions? Contact us.
C++
Web Development
Wireless
Latest Tips
Open Source


   Development Centers

   -- Android Development Center
   -- Cloud Development Project Center
   -- HTML5 Development Center
   -- Windows Mobile Development Center