Many COM APIs make extensive use of Variants and this can degrade translation quality. In fact, I was recently working on upgrading a commercial VB6 application to C# and I encountered the following error in the C# build log:

ERRNUM: CS0029: Cannot implicitly convert type 'byte' to 'byte[]'
NETSRC: ... frmAttachWindow.cs@287
bbuf = Convert.ToByte(vbuf);
ERRNUM: CS0029: Cannot implicitly convert type 'byte[]' to 'object[]'
NETSRC: ... frmAttachWindow.cs@291
vbuf = sendbuf;

Looking at the VB6 code I find this:

Dim vbuf As Variant
Dim bbuf() As Byte

and later this

vbuf = frmMain.MSComm.Input

I suspect frmMain.MSComm.Input is a member of an MSCOMM control. I look up the definition of this member in the generated interface description file (IDF) for MSCOMM and I find this:

   <class id="IMSComm" parent="IDispatch" default="_CommPort">
...
      <property id="Output" type="Variant" status="InOut"/>
      <property id="Input" type="Variant" status="InOut"/>

And change it to this

   <class id="IMSComm" parent="IDispatch" default="_CommPort">
...
      <property id="Output" type="Byte[]" status="InOut"/>
      <property id="Input" type="Byte[]" status="InOut"/>

I save the updated IDF in my usr folder so it will take precedence over the generated one.

I take a snapshot of the last translation, and I rerun the translation using the new IDF.

Comparing the snapshot (left) to the new results (right) shows the dramatic improvements – and the orginal C# build errors are gone.

gmStudio technology allows a migration team to modify the type information for your COM APIs. This will result in cleaner more correct translations. Modifying type information can also be used to direct the tool to replace COM components with .NET classes. See Custom COM Replacement for additional information.

Browser not supported