When converting a type library for use with a .NET client the TlbImp.exe tool (used by VB Migration Partner behind the scenes) creates both an interface type (e.g. ADODB.Recordset) and a creatable class whose name has a “Class” suffix (e.g. ADODB.RecordsetClass). When migrating the VB6 client application to VB.NET, VB Migration Partner preserves this distinction and uses the interface name in plain Dim statement and the creatable class name in As New clauses, for example:
Dim rs As ADODB.Recordset
Dim rs2 As New ADODB.RecordsetClass
There are a number of reasons for following this approach. For example, consider the following VB6 code:
Dim rs As New ADODB.Recordset
Sub Test()
If rs.Connection Is Nothing Then Exit Sub
End Sub
VB Migration Partner correctly translate the above code snippet to VB.NET as follows:
Dim rs As ADODB.RecordsetClass
Sub Test()
If AutoNew6(rs).Connection Is Nothing Then Exit Sub
End Sub
Notice that the AutoNew6 helper method ensures that a new ADODB.Recordset object is istantiated if and only if the rs variable is Nothing when it is referenced. However, for the AutoNew6 method to work correctly, the type of the variable passed to it must match a creatable class, hence the variable is declared of type ADODB.RecordsetClass. If you drop the “Class” suffix, the VB.NET compiler complains with the following error message:
Type argument 'ADODB.Recordset' must have a public parameterless instance constructor
to satisfy the 'New' constraint for type parameter 'T'.
While the “Class” suffix hampers neither code readability nor performance, a few developers might want to get rid of it. VB Migration Partner doesn’t currently offer a pragma to suppress the Class suffix, however you can usually achieve this goal by means of one or more project-level PostProcess pragmas. For example, this pragma gets rid of the “Class” suffix for all the objects in the ADODB and RDO libraries: