In some cases – most notably when converting groups of two or more VB6 projects – it might be necessary to add a COM reference to the migrated application. To explain when and why this step might be necessary, imagine the following scenario.

Say that you have Project A (a standard EXE project) that references Project B (an ActiveX DLL or Control) in the same group and that one or more classes defined in Project B expose public methods and properties that take or return values whose type is defined in Library C (a separate COM type library). Project B has therefore a reference to Library C, but Project A doesn’t require such a reference. A very common case is when a control defined in Project B exposes a property that returns an ADODB.Recordset object (or another enumerated type defined in the ADODB type library), without Project A having a reference to the ADODB library.

Even without a direct reference to Library C, Project A works well in this scenario. In fact, VB6 applications require a reference to a COM type library only if they define an object of a class defined in the type library; no direct reference to the type library is strictly required if applications use objects from another DLL that take or return objects from the type library.

VB.NET and the .NET Framework platform is less forgiving than VB6. If Project A uses one or more objects defined in Project B and these objects have public members that take or return objects defined in Library C, then Project A must have a reference to Library C.

The simplest way to add such a reference is by means of an AddReference pragma in the original VB6 code. For example, the following pragma adds a reference to the ADODB primary interop assembly:

'## AddReference "C:\Program Files\Microsoft.NET\Primary Interop Assemblies\adodb.dll"