The VBUC and graphical control migration
The Visual Basic Upgrade Companion transforms the built-in VB6 controls to their corresponding .NET counterpart. For these controls, the properties are extracted and translated into their equivalents when possible or upgraded to the closest approach available.
The list of all the intrinsic VB6 controls and their respective target structures for the latest version of the VBUC can be found at the following URL: https://www.mobilize.net/vbtonet/vbuc-basic-features/intrinsic-control-mappings
When a property, method or member is not supported, all the references to that member are replaced with an informational message that pauses the execution to allow the user to select whether to ignore the missing reference or to break the execution and implement the missing functionality. This feature is available not only for inherent graphical controls but for all the entire application, as explained in the following article:
A Third Party Control is a component that is not included as part of the built-in set of VB6 controls or that has to be read from an external binary file (ocx, dll) . This definition applies even if it’s built by Microsoft of by your own company.
Note: User controls are handled differently. When a VB6 project includes a definition for a user control, and all the required source code is included in the migration solution, the VBUC will upgrade the control definition and its references to .NET. The VBUC upgrades user controls and their dependencies, avoiding the use of COM interoperability.
In the context of this document we will work with the following definition of a third party control:
Third Party Control: the graphical user interface components and controls for which the source code is not included in the VBUC migration solution.
To better understand this idea, picture the following example:
There is a VB6.0 application made up of the following two folders:
- User Control: folder with the source code for UserControlOne, an ActiveX control compiled into an OCX file
- Using the User Control: Contains the source code for UsingUserControlSameSolution, a standard EXE that uses the UserControlOne ActiveX component
Depending on how you configure the Visual Basic Upgrade Companion Migration Solution, the references to the UserControlOne component will be handled as a third party or not:
- If the migration solution includes both projects, the VBUC will upgrade the UserControlOne ActiveX Control into a native .NET control, and modify the references to this control in the UsingUserControlSameSolution EXE to the upgraded version of that control. In this case, the reference to this user control will be considered as internal, since the source code is found as part of the migration solution.
- On the other hand, if the migration solution only includes the Using the User Control folder, with only the source code for the UsingUserControlSameSolution EXE and a binary reference to the registered UserControlOne OCX, the VBUC will not be able to identify the source code and will consider the reference as an external reference. This means that the source code for the OCX is not available, and the VBUC will create a Runtime Callable Wrapper to continue using the OCX from the .NET code.
This second scenario is what happens when a 3rd party control is added to the project.
The Visual Basic Upgrade Companion upgrades a limited set of Third Party Controls to their .NET equivalents. This set was created based on requirements from ArtinSoft’s migration experience. These Third Party Controls are ported to native .NET components, which includes the built-in .NET controls included with the .NET Framework, new .NET version of the control from the same vendor and equivalent .NET controls from different vendors. The supported controls list is constantly being expanded, both with new controls being supported and with increased coverage of the currently converted controls.
The VBUC keeps the references to the unsupported controls by means of a Runtime Callable Wrapper. The VBUC uses the “tlbimp.exe” utility from the .NET Framework to create these wrappers (Type Library Importer (Tlbimp.exe))
The resulting DLL will allow the managed .NET code to coexist with COM components using specific marshalling techniques. This method is the fastest way to get your code into .NET, since the resulting application after the migration includes the same controls as in the original, and as such reduces the amount of manual effort required to achieve functional equivalence. It, however, has the downside of keeping unsupported legacy controls, which can represent an evolutionary obstacle in the long run.
The Visual Basic Upgrade Companion is built on top of a proprietary Artificial Intelligence-based technology that allows the description of transformation rules, special cases and exceptions on specific patterns with ease. The simple syntax and fast development approach allows us to satisfy our customer specific needs with minimal response times. New migration rules are constantly added when migrations are performed by ArtinSoft’s Consulting Services; and they are also offered for large enterprise customers to obtain software migration solutions that satisfy very specific technical requirements
The customization requirements often include adding support for additional Third Party Components and special transformations for their usage patterns. This type of extensibility is very powerful since it allows the definition of highly complex transformations, but it depends on ArtinSoft’s engineering team to provide these extensions.
With the latest version of the Visual Basic Upgrade Companion, ArtinSoft provides their customers with a simple customization option to add partial support for the migration of Third Party Controls. This is called Custom Maps, and will be covered in the next section.