Estimating effort to migrate your application from Visual Basic 6.0 to .NET

  • Article

The following three tools can help you better understand what would be involved to migrate your VB6 applications to Microsoft.NET

Microsoft's VB6 Code Advisor Tool

This tool from Visual Basic Resource Center site, installs as an Add-In in the VB6 IDE.

clip_image002

The tool analyses your code for potential upgrade issues, generates a report and puts detailed comments in your code. It does assume that you are upgrading using Visual Studio 2005 rather than Visual Studio 2008, but it includes a facility to let you add in your own custom rules. You need to dig around in the folder the add-in installs to and locate FixItRuleTool.exe and FixItRuleTool.rtf to add your own rules. The tool’s ReadMe.txt also warns that help file is out of date, so the tool is aware that the upgrade wizard supports WebClasses, the Clipboard object and COM+.

ArtinSoft’s Visual Basic 6.0 Upgrade Assessment Tool

This tool analyzes the application components and the relationships between them from a migration perspective, which considers elements, constructs, and features that consume significant resources during an upgrade project. It generates a group of reports that are used as a basis for further calculations related to task effort and cost.

  • This first one is called MainReport.xls and contains all the configuration settings and summaries of the effort estimates.
  • The second report, called DetailedReport.xls, is linked to the previous one, and it shows detailed information about the content of the application.

Code Architects VB6 Bulk Analyzer

This is a command-line utility that gathers information on the VB6 projects and source files inside a specified directory tree and then creates a concise but quite thorough report.

The command VB6ANALYZER c:\firstapp c:\secondapp  /out:c:\report.txt will generate a named VBAnalyser_Report.txt, in the current directory. The report contains:

  • number of projects and source files, grouped by type
  • statistics about the source code (code lines, empty and remark lines, etc.), number of methods, properties, etc.
  • statistics about ActiveX classes (grouped by their Instancing property, number of MTS classes, etc.)
  • all the type libraries used in all projects, with how many times the typelib is referenced
  • names of all used controls and components, with a count beside each control
  • list of all the Declare definition, with number of occurrences of each declare
  • list of problematic keywords (GoSub, On...Goto/Gosub, VarPtr, ObjPtr, StrPtr, etc.), with number of times the keyword is used
  • list of problematic data types (Variant, fixed-length strings, etc., with number of times the keyword is used
  • list of problematic control properties, methods, events (e.g. members related to classic Drag-and-drop or DDE)
  • list of problematic constants (e.g. adOpenDynamic and adOpenKeyset means that a piece of ADO code can't be easily ported to ADO.NET)
  • list of COM classes that are instantiated via CreateObjects
  • list of OLEDB data providers explicitly mentioned in a connection string