Why should I upgrade my VB 6.0 applications to .NET?
There are several drivers for a VB to .NET migration:
- Integrate Windows, Web, Office and Mobile solutions
- Boost system performance
- Ease deployment
- Improve the maintenance of an application
- Increase developer productivity
- Consolidate your company's valuable software assets
- Avoid obsolescence of outdated software (support for VB 6 ended on April 8th, 2008 ).
- Maintain competitive advantage
The decision can be justified by many factors, like technological constraints, legal/regulatory compliance requirements and lack of resources for older languages, all of which decrease an organization’s agility, boost operating costs and tend to destabilize its competitive position.
Should I migrate to VB.NET or C#?
VB.NET and C# are Object Oriented programming languages, with full functionality for inheritance, interfaces, patterns and more inherent object oriented constructions and behavior. The existence of the .NET framework allows the use of types, libraries and more in both languages, which means that any programmer can read and write source code from any of these two languages without major issues, and the performance is the same thanks to the CLR (Common Language Runtime) environment.
There are differences between both languages that you should analyze. For example, if most of your developers have been working with VB 6.0 they will probably feel more comfortable moving to VB.NET. On the other hand, if you have a Java or C++ code base coexisting with your VB applications, it might be better to migrate your VB6 systems to C#, a language that is more familiar to programmers exposed to other object oriented languages due to its syntax, constructions and usability.
Also, if you are considering web enabling your application or moving into the cloud at some point, we currently have a solution that migrates from C# to Silverlight or to Windows Azure (it can be done directly from VB6 too), choosing C# will provide you with more more options in the future.
Should I migrate directly from VB 6.0 to C#, or is it reasonable to use a 2-step strategy (VB6 –> VB.NET –> C#)?
We’ve heard suggestions that a double path approach is best for those who choose to migrate their VB6 applications to C#. This suggestion comes from those who offer a solution that only converts to VB.NET, and they say it’s irrational to even think about jumping from VB6 to any .NET language other than VB.NET. At Mobilize.Net, we know this advice is wrong and have proven it wrong hundreds of times.
The differences between Visual Basic 6.0 and any .NET framework compliant language is noticeable, since the former is a procedure intensive, non structured programming language which its strongest feature was the “visual” designer used to build the graphical user interface, while the latter languages are fully object oriented.
The differences between VB6 and C# or VB.NET are estimated and resolved in most scenarios by the Visual Basic Upgrade Companion tool. To be more specific, let’s use a VB6 inherent feature, which is also present in VB.NET by the way: the “OnError Goto” construct, an unstructured error handling technique to jump to a specified code segment, and “OnError Resume Next”, used to continue with the next instruction in the source code in case there is an error. Both structures make more complex the path tracking for the application control during runtime, and complicate the debugging process and increases the time needed for the application maintenance because of its complexity and lack of readability.
The VBUC is able to remove this error handling routines in the generated source code, ensuring the resulting source code will behave as much as object oriented as possible. The routine used to replace these structures is the “Try … Catch” blocks, simplifying the application flow path by having a managed interception of each error (exception). The “On Error GoTo” and “ResumeNext” constructs are not one-to-one equivalents with the “Try … Catch” block, but it is the simplest way to manage error occurrences without creating the same complexity effect found in the VB6 intrinsic routines.
The upgrade process from VB6 to C# is easier with the Visual Basic Upgrade Companion because of the considerations taken to ensure the resulting code’s quality will be the highest. Some of these considerations are strict typing, event declaration and invocation, error handling, refactoring from modules to classes, parameter transmission, arrays with lower bounds to zero, array dims and redims, default instances for forms, classes and user controls, indexer properties, “with” replacement for full naming, usage of return statements, interface creation for implemented classes, variable initialization, brackets and case sensitiveness refactoring, and more. After a deep analysis of the original source code, the Visual Basic Upgrade Companion is able to perform all the refactoring and transformations needed to accomplish all the previously listed items, delivering the greatest levels of automation and taking the VB6 to .NET migration to higher levels of excellence.
All the Visual Basic 6 inherited features in VB.NET which C# lacks can be modeled with different constructions to accomplish functional equivalence. Using those alternate constructions the code will look more C# native instead of a bizarre adaptation from two extremely different programming paradigms.
All this means that a VB6 to VB.NET upgrade will consume the same effort as migrating to C#. The Visual Basic Upgrade Companion’s architecture allows the C# generation to be done directly from the analysis over the original VB6 source code, allowing the upgrade process to be done in one strike.
This one-step migration avoids the use of third party tools to do the final step from VB.NET to C# because the resulting code is built directly into C# and not in a VB.NET intermediate representation. A two-step migration will ruin the overall precision of the upgrade task because two different tools may differ in the code refactoring techniques, resulting in poor source code quality with almost no readability.
Mobilize.Net has successfully upgraded billions of lines of code from VB6 to C#, and counting more everyday. Based on this experience we can assure you that a VB6 to C# migration is possible, reliable, and in fact, one of the most popular choices among large real world organizations.
Visual Basic Upgrade Companion:
What is the Visual Basic Upgrade Companion?
The Visual Basic Upgrade Companion is a VB 6.0 to VB.NET or C# migration tool. This advanced tool provides a cost-effective solution that features ADO to ADO.NET conversion, variable type resolution ("late binding" problem), error handling replacement, use of .NET native libraries, code refactoring, third party component mappings, migration of mixed VB6 and ASP projects, multi-project upgrade support, and much more.
Pricing for the tool basically depends on the amount of lines of code (LOC) to be migrated. Licensing is per application and you can run the Visual basic Upgrade Companion several times upon the same VB6 files for which you originally purchased the product.
Only code lines and design lines are taken into account, excluding blanks and comments. Also, duplicate lines are not charged, though these cases require a special license (contact us if that’s your case).
You can determine application size, and therefore the license you need to purchase, running our free VB6/ASP Assessment Tool against the application to migrate.
For licenses prices please contact us and we will provide you all the information you need to migrate your VB6 application.
If I have an application comprised of four projects (.vbp files) of 25,000 lines each, can I buy just one 25K LOC license to convert the whole system?
According to the license agreement, for generated code ownership reasons you must purchase a license for the total amount of lines of code you intend to migrate (comments and blanks excluded).
One of the advantages of the Visual Basic Upgrade Companion is its advanced multi-project support. Since there are normally references between projects, it’s highly advisable to run the tool on all the projects at once and not convert them separately, taking advantage of the reference resolution capabilities of the VBUC. If you have four 25K LOC projects on the same application, a 100K LOC license will avoid project interoperability and file duplication issues, thus reducing the subsequent manual effort.
What if I have four applications, and the sum of all the projects in each one is 100,000 lines? Can I buy just one 100K LOC license to convert all of them?
Licensing is per application, so you will need one license for each one. That is, four 100K LOC licenses. However, we can provide special pricing if you have several applications to migrate, in the form of a corporate or site license. Please contact us for more information.
Can I customize the Visual Basic Upgrade Companion?
Yes, Mobilize.Net can develop additional mappings to migrate third party components and additional customization rules to convert programming patterns or structures so they become more ".NET-like". By customizing the Visual Basic Upgrade Companion according to the characteristics of your application and your target requirements the percentage of automated conversion is increased, thus reducing the manual effort required during a VB to .NET migration project.
How dependent is the converted code on support (helper) classes?
The migration philosophy behind the Visual Basic Upgrade Companion is to produce native .NET code with no dependency on the legacy platform or any third-party runtime, so that you can effectively take control of the evolutionary path of the migrated applications without any restrictions. To ensure this, the Visual Basic Upgrade Companion’s artificial intelligence-based engine generates VB.NET or C# code with the direct support of the .NET framework, but whenever this is absolutely not possible, due to API differences or code readability and maintenance, the tool makes use of support classes. However, you always have access to the library’s source code so that there’s no dependency on Mobilize.Net.
Other VB to .NET migration tools rely heavily on extensive .dll libraries containing lots of functions and classes that emulate Visual Basic 6 behavior in the .NET platform. For example, they generate one class per each VB6 control, so that every single control used in the migrated application is an instance to a class located in the proprietary library, without even one declaration of an inherent control; all the buttons, control arrays, text boxes, everything, is referenced in that library’s classes.
Building a .NET version of the VB6 environment may simplify the migration process by using those emulation functions and classes contained in the proprietary library, but this definitely compromises the final application’s maintainability. A helper library is meant to aid in the minor nip & tuck needed to get the original application running in .NET, not to “host” it. VB6 emulation in the .NET environment will keep all the patterns and constructions used in the source language, resulting in a poorly translated application which depends completely on this “support” library.
Besides getting access all the features found in the .NET framework, one of the main objectives of upgrading a given application from VB6 to .NET is to move into a fully supported environment. That’s why the Visual Basic Upgrade Companion generates source code that is native .NET native, using inherent controls, functions, constructions, keywords, etc.
What controls does the Visual Basic Upgrade Companion support?
The Visual Basic Upgrade Companion supports all the inherent VB6 controls and all of its properties, along with dozens of third party libraries from different vendors. The tool includes a set of plug-in dlls designed to automatically convert functionality from ActiveX libraries to .NET libraries, thus saving an important amount of time in code analysis and manual modifications. Each plug-in dll contains the transformation specifications for each third-party library.
If there is a library employed in your application that has no equivalent in .NET it can be accessed through COM interoperability without many problems, but we can also customize the Visual Basic Upgrade Companion to generate the desired mappings to inherent .NET components or other third party libraries.
For detailed information about supported controls and how they are upgraded to the .NET platform please contact us.
How effective is the Visual Basic Upgrade Companion at converting an application’s UI?
The Visual Basic Upgrade Companion has many features that help you to upgrade the applications user interface (UI):
- Successful default properties extraction from the original VB6 controls
- Use of inherent .NET controls and constructions, which ensures the resulting graphical UI will look as natural as possible
- No proprietary runtime, which elevates the code maintainability and eases the process of future additions to the existing UI
- Intelligent implementation of upgrade issues like control arrays and default properties resolution even in late bound usages
- Extensibility model that allows the tool to adapt to particular code patterns and programming techniques
Also, during the conversion process, the Visual Basic Upgrade Companion will display all the conflicts and issues related to references to third party libraries and other resources.
Can the Visual Basic Upgrade Companion convert VB6 native functions to .NET native functions?
Yes. There is a mechanism that allows the conversion of VB6 intrinsic library elements to .NET native libraries. This basic mechanism supports the following VB6 libraries:
How does the Visual Basic Upgrade Companion handle Windows API calls?
The Visual Basic Upgrade Companion uses two approaches to deal with API functions/types. The first method consists in leaving the code as it comes from VB6, and API functions are still used in the converted code. Manual effort is required as certain Marshalling tasks could be necessary to pass managed data structures to the unmanaged code (API methods).
The Visual Basic Upgrade Companion provides a second approach where the final objective is to replace API members with .NET framework native functionality. Currently, the tool converts a subset of API members to .NET equivalents, but it can be extended by adding custom mappings for new API members.
For a comprehensive list of Windows API functions and their .NET equivalents, please refer to this MSDN page