locked
Converting VB6 to C#

Answers

  • The problem with conversion is that VB6 and .NET have totally different programming paradigms. VB6 was a procedural and object-based language, whereas .NET is fully object oriented, and this means that the way you would probably want to design your API will be rather different. The error handling capabilities are totally different, i.e. VB6 uses On Error with error numbers, whereas .NET uses exception classes and structured error handling, so the way you would want to design the exception management would be totally different (note that this also forms part of the API). In addition, things that you would have written yourself before now can often be handled by framework classes so you would write code in a different way too.

     

    Personally I don't see the value in converting code en-mass. It presumably works in its current form, and as VB6 produces COM components it can interoperate with .NET code very easily. Have you considered the approach of writing new code in C#, and then interoperating with the existing VB6 code where possible, and selectively rewriting sections of the VB6 code as and when you need to alter or extend them? This allows you to focus on new things that will add business value, and gradually convert the parts of the codebase that need it (which may not be all of it) rather than spending a long time converting code, which will add no business value.

    Sunday, July 22, 2007 11:35 AM
  • The first one is not a product, but consulting services.  The second one is a VB.NET to C# product.

    The last two are indeed products converting VB6 to C#.  There is one that you missed:

    http://www.deluxsoftware.com/deluxintro.html

     

    VB6 to C# directly is a big leap though.  Converters that attempt to convert both the underlying framework and syntax together are rarely very accurate.  I'd recommend doing this in two steps: first upgrade to VB.NET using the VS upgrade wizard (and lots of sweat).  Then convert to C#, using one of the various tools out there - we also make one, but that's all I can say without getting slapped on the wrist on this forum Wink.

     

    Friday, July 20, 2007 2:34 PM

All replies

  • The first one is not a product, but consulting services.  The second one is a VB.NET to C# product.

    The last two are indeed products converting VB6 to C#.  There is one that you missed:

    http://www.deluxsoftware.com/deluxintro.html

     

    VB6 to C# directly is a big leap though.  Converters that attempt to convert both the underlying framework and syntax together are rarely very accurate.  I'd recommend doing this in two steps: first upgrade to VB.NET using the VS upgrade wizard (and lots of sweat).  Then convert to C#, using one of the various tools out there - we also make one, but that's all I can say without getting slapped on the wrist on this forum Wink.

     

    Friday, July 20, 2007 2:34 PM
  • The problem with conversion is that VB6 and .NET have totally different programming paradigms. VB6 was a procedural and object-based language, whereas .NET is fully object oriented, and this means that the way you would probably want to design your API will be rather different. The error handling capabilities are totally different, i.e. VB6 uses On Error with error numbers, whereas .NET uses exception classes and structured error handling, so the way you would want to design the exception management would be totally different (note that this also forms part of the API). In addition, things that you would have written yourself before now can often be handled by framework classes so you would write code in a different way too.

     

    Personally I don't see the value in converting code en-mass. It presumably works in its current form, and as VB6 produces COM components it can interoperate with .NET code very easily. Have you considered the approach of writing new code in C#, and then interoperating with the existing VB6 code where possible, and selectively rewriting sections of the VB6 code as and when you need to alter or extend them? This allows you to focus on new things that will add business value, and gradually convert the parts of the codebase that need it (which may not be all of it) rather than spending a long time converting code, which will add no business value.

    Sunday, July 22, 2007 11:35 AM
  • There is now a commercial need to convert from VB6 as Microsoft no longer support VB6, therefore many companies will no longer accept VB6 software, even if it is currently functioning perfectly well.

     

    I am currently converting VB6 code to C#. This application has 600,000 lines of code, so this is a big job. I have used one of the conversions tools that the OP listed; it only gives a very rough first draft (that compiles with 100s of warnings and errors for a typical project). I then have to manually fix and refactor most of the code in each method to get a working version. The conversion tool is useful because it does some of the donkey work, but you still need to put in a lot of effort afterwards. And you still end up with a lump of procedural code (no o-o). But for us this is still cheaper than a complete rewrite.

     

    I have also looked at out sourcing to a consultancy company; they seem to do a very good job, and may be more cost effective (essentially they use their own conversion tool which is probably one of the best, so this saves them a lot of effort).

     

    Please note I have deliberately not mentioned any names.

    Monday, July 23, 2007 11:46 AM
  • The reason shellshock gave, is exactly the situation i am in. Like i sais, i am very much aware of the manual work that still has to be done, but we are looking for the best solution so far, so that the most of the donkey work will be done by the tool.

    I found another one by the way which generates an XML file from VB6 code, the XML can be used to generate a UML Model, which again can be used to generate C# code. Hmm i really am curious how that will turn out, but i heard it was failry mentioned in the area of "application replatforming"

    http://www.omnext.nl/

    When we will start using a tool i will post my findins here for anyone who is interested. Thanks for all the help so far Big Smile
    Thursday, July 26, 2007 8:28 AM
  • As other replies indicate VB6 and C# are very different so there are many needs and opportunities to redesign, refactor, not to mention just clean up VB6 codes as they are moved to C#.  Also as other replies indicate the output of most conversion tools helps -- but it also leaves a lot to be fixed and finished by hand which is expensive, tedious, and error prone.   The same could be said for doing work manually: at the beginning, you will have a lot of work ahead of you -- in terms of design work, testing, and coding.  However, when you are working by hand -- from scratch -- you will *also* have a mountain of work to do in terms of gathering, refining, and validating functional requirements.  In fact in a "from-scratch" rewrite of a very large mature system, the resources you will spend on functional requirements gathering and verification can easily be greater than any other aspect of the migration effort.

    I faced this problem head on back in 2005 -- we had over 1M LOC of mature, business-critical VB6 code organized into over 500 inter-related VBPs.  We were not so arrogant or wasteful to think we should rewrite the codebase from scratch.  We also had to do the upgrade while the VB6 was changing for our customers' business projects and maintenance.  We had experience with "from scratch" C#/.NET coding and had created development and architecture standards for .NET code. We wanted to make sure the migrated codes were consistent with our new design standards. 

    We ended up working with a unique VB6-to-.NET compiler using what the vendor called a tool-assisted rewrite methodology.  We had a small group of .NET developers work with the vendor to make the tool produce better C# codes.  We identified the things in the C# that we did not like: the things where the translations did not fit our standards and where the translations were just plain wrong.  The vendor helped us fix the tool and its configuration to improve the translations so they were correct and they fit our standards.  We iterated on this "translation tuning" process until the automatic translations were good enough to be finished easily by hand and deployed as part of our standard ongoing release cycle.  I was so inspired by our success that I started a company to further refine the technology and offer it to the VB6/ASP community as a product. 
    A case study of our migration program is at 
     www.greatmigrations.com.

    Disclaimer: I work for Great Migrations.

    • Edited by MarkJuras Friday, November 06, 2009 2:59 PM
    Thursday, November 05, 2009 3:48 PM
  • Be careful - you work for Great Migrations.

    I started out with a fairly blatant promotional approach many years ago and I quickly realized (with the help of some discipline from moderators) that it's far better to try to offer help in these forums in your area of expertise and let people make their own connections.

    Convert between VB, C#, C++, & Java (http://www.tangiblesoftwaresolutions.com)
    Thursday, November 05, 2009 4:56 PM
  • You are wrong the first one is not a service. It is a product that you can even download a trial following this link in MSDN

     

    http://msdn.microsoft.com/en-us/vbasic/ff793478

    This tool will convert VB6 to C# and VB.NET

    They also have www.silverlightmigration.com and www.azuremigrations.com

    As solutions for moving your VB6 application to Silverlight and Azure

    Sunday, May 22, 2011 6:55 AM
  • Yes it is a product now - 4 years ago it was strictly a service.


    Convert between VB, C#, C++, & Java (http://www.tangiblesoftwaresolutions.com)
    Sunday, May 22, 2011 1:59 PM