In most cases, VB Migration Partner correctly converts VB6 project that reference one or more type libraries. Problems may arise if you run VB Migration Partner on a computer that is different from the computer where the original VB6 application was developed, because the type library might have a different version or be stored in a different location on disk. We have found that the following three issues might arise:

1. VB Migration Partner locates the type library by searching for its GUID in the registry; this mechanism works correctly if the type library has a different version number OR the type library is stored in a different directory. However, the type library installed on the computer where you run VB Migration Partner has a different version AND is stored in a different disk location, then the type library in question can’t be located correctly.
2. Assume that your VB6 app uses the Microsoft Office 11 type library and that you later update to Microsoft Office 12 (a.k.a. Microsoft Office 2007) or move the VB6 project to a computer that has Microsoft Office 12 installed. It is easy to prove that the compiled VB6 application correctly uses the version of Microsoft Office that is newer than the version it was compiled against. However, the original VB6 project still references the older version and attempting to convert the project now fails with an “unrecognized type library” migration error.

The solution to both issues a) and b) is simple: open the original VB6 project, save it, and close it. When VB6 saves the project, it updates the type library reference and makes VB Migration Partner happy. To ensure that the .vbp file updated with the correct type library references, open the References dialog and uncheck and then re-check one of the selected libraries.

3. VB Migration Partner migrates type libraries using the TlbImp.exe tool behind the scenes and preserves the names of the classes defined in the VB6 code. For example, the Word.Application object is still referenced as Word.Application in the converted VB.NET. This approach works fine in most cases, but fails when Visual Studio ignores the .NET interop assembly generated by VB Migration Partner in favor of a Primary Interop Assembly (PIA) provided by the original type library’s author (Microsoft, in this example). The problem, in this case, is that the root namespace of the Microsoft Word’s PIA is “Microsoft.Office.Interop.Word” instead of just “Word”.

To cope with issue c), VB Migration Partner supports the AddImports pragma, which creates a project-level Imports with the name you specify. In this specific case, therefore, the solution is to embed the following line in the original VB6 code:

    '## project:AddImports Microsoft.Office.Interop

so that the all references to the Word.Application object are resolved correctly under VB.NET.