Another common question among our customers is: does VB Migration Partner handle 3rd-party ActiveX controls? Here’s a simple question that calls for an articulate answer.

First and foremost, VB Migration Partner can convert virtually all the controls in the VB6 toolbox, plus a few which aren’t distributed with VB6 but are quite common in VB6 applications, such as the ScriptControl and the WebBrowser controls. The only VB6 controls that VB Migration Partner doesn’t currently convert are the OLE container control, the Repeater control, and the Coolbar control.

It’s important to notice that most of the controls in the VB6 toolbox are migrated to “fully managed” Windows Forms controls defined in our support library. The exceptions to this rule can be gathered in two distinct groups: invisible controls (INet, MAPISession, MAPIMessage, MSComm, Winsock, ScriptControl) and visible controls (DataGrid, MSHierarchicalFlexGrid, MS Chart, and MM Control). Controls in the first group are rendered as wrappers around the original type library (using the TlbImp tool), whereas controls in the second group are substituted by .NET wrappers created using the AxImp tool.

By default, all the controls that VB Migration Partner doesn’t recognize are rendered as VB6Placeholder controls, which appear as red rectangles on VB.NET forms. In most cases you’ll see no compilation errors, because VB Migration Partner generates a “dummy” form-level Object variable named after the original control, therefore all control references are successfully resolved at compile time. (Needless to say, any reference to these variables would fail at runtime, but at least you can test all the forms in your apps that don’t contain unsupported ActiveX controls.)

If the ActiveX control is authored in VB6 and you own it’s source code, you can use our tool to migrate it to VB.NET. In this case VB Migration Partner generates all the attributes that VB Migration Partner itself needs to recognize the new VB.NET UserControl as a replacement for a VB6 control. All you need to do is recompile the VB.NET UserControl, deploy the DLL in VB Migration Partner’s main folder (C:\Program Files\Code Architects\VB Migration Partner by default), and try to migrate the main application again.

Let’s see now what your options are if your VB6 application contains ActiveX controls from other vendors and the control hasn’t been authored in VB6 or you don’t have the its source code.

The simplest and most cost-effective strategy is simply to replace the VB6Placeholder control with the .NET Framework control that most closely resembles the original ActiveX control. For example, you might decide to replace a 3-rd party grid with the DataGridView control and then fix all the references to properties, methods, and events. Needless to say, this strategy can take anything from a five minutes to a few hours, depending on how much the VB6 and VB.NET controls differ. An additional problem of this approach is that it doesn’t work well with the convert-test-fix cycle: if you later re-convert the VB6 application you’ll have to re-apply your fixes.

Alternatively, you can use the AxWrapperGen tool that we provide with VB Migration Partner. This utility generates the VB.NET source code of an “alias” class that wraps the ActiveX control and that is decorated with all the attributes that VB Migration Partner requires to recognize the class as a replacement for the ActiveX control. You must recompile this project and deploy the executable DLL in VB Migration Partner’s folder, as you’d do with UserControl classes migrated from VB6.

The last option requires you write a “pure” VB.NET alias control that replicates the same properties, methods, and events as the original ActiveX control – but doesn’t depend on the ActiveX control itself - and then decorate the class with the attributes that VB Migration Partner. In most cases, you can have the VB.NET class inherit from the .NET control that offers as many similarities to the original ActiveX control as possible. For example, an alias class for the Microsoft Calendar control should derive from the MonthView control:

     <VB6Object("MSACAL.Calendar")> _
     Public Class VB6Calendar
           Inherits MonthView
           Implements IVB6Control
     End Class

Alas, this option is also the most complex of the group, because you need to understand how VB Migration Partner’s support library worksand we haven’t completed this portion of the documentation yet.

To summarize, here’s what you can do:

  • Before doing anything else, check our Web site to see whether we’ve created an “alias” class for the control. We plan to add support for the most common 3-rd party controls when we have time and enough requests from our customers. The simplest way to be informed of our additions is subscribing to our newsletter.
  • If you have the control’s VB6 source, the strategy is clear: just convert it to VB.NET and deploy the compiled DLL to VB Migration Partner’s folder. This approach delivers a fully managed solution and supports the convert-test-fix cycle.
  • If you don’t have the source code, the AxWrapperGen utility offers the simplest and quickest strategy. The downside is that the control isn’t fully managed, it still depends on the original ActiveX control, and it might suffer from a few bugs in the COM Interop portion of the .NET Framework.
  • If you’ve used the control sparingly in your application, you can manually replace all ActiveX control occurrences after the migration with the VB.NET control that most closely resembles the original control. This option isn’t always possible or practical, and doesn’t support the convert-test-fix cycle.
  • A good compromise between the last two strategies: you use the AxWrapperGen utility to generate an “alias” class and then use such a class during the convert-test-fix cycle. When the VB.NET application is working fine and you don’t plan to run VB Migration Partner again, just throw away the “alias” control and manually replace all its occurrences with a fully managed controls.
  • If you have time, write your own “alias” class for the ActiveX control. (This option will be viable when we release detailed documentation about alias classes.)
  • If you don’t like any of these options, contact us for writing an “alias” control for you.