Adding a VB6 reference in Visual Studio gives "Type library importer encountered an error during type verification"

Question

I am in the process of convering a rather large project written in VB6 into C#. Given the size of the project being moved, it is being done in phases over the course of 18-months. I am running into an issue with adding a reference of a VB6 ActiveX dll to a .Net project.

If you follow exactly these steps, you too should be able to recreate the problem.

I have written an interface in .Net that is COM visible:

<ComVisible(True)>
Public Interface ITestInterface
    Property A As String
    Function TestMethod() As String
End Interface

By selecting "Register for COM interop" in Compile tab of project properties, you get a TLB file.

I've created a VB6 project that references this TLB and a class that implements the interface exposed.

Implements ITestInterface

Private mA As String

Public Property Get ITestInterface_A() As String
    ITestInterface_A = mA
End Property

Public Property Let ITestInterface_A(ByVal value As String)
    mA = value
End Property

Public Function ITestInterface_TestMethod() As String
    ITestInterface_TestMethod = "From VB6"
End Function

If I set the Component tab of project properties in VB6 to use "Remote Server Files" then a TLB is automatically created when compiling. I can view that TLB in OleView and see the following (in addition to the details of the concrete implementation done in VB6 of the interface defined in the .Net project):

// typelib filename: TestVB6Interface.dll

[
  uuid(**EF005573-BFC7-436D-A382-F906CA09F94A**),
  version(3.0)
]

// ... some other stuff

// TLib :     // TLib :  : {79EC733A-0267-4506-8D38-C4D4655E0755}
importlib("SimpleDotNetLibrary.tlb");

Now, I create a completely new .Net project. If I add a reference to the VB6 dll, I get the following error:

Could not resolve COM reference "ef005573-bfc7-436d-a382-f906ca09f94a" version 3.0. The type library importer encountered an error during type verification. Try importing without class members.

However, if I launch a Visual Studio Command Prompt and run the following:

tlbimp TestVB6Interface.tlb /out:TestVB6Interface.MyInterop.dll

Then I can add that dll as a reference in my .Net solution and it works perfectly fine.

My question. What is tlbimp doing on the command line that is not being done when I just add the reference directly? When the message in Visual Studio says "try importing without class members" how exactly do I do that within Visual studio? I know how to do that in tlbimp.

I apologize for the wall of text, but I wanted to describe the situation as best I could keeping the information I felt was relevant.

Synder

We did (kinda). The VB6 class that implements the .Net interface needs to be set to "Attribute VB_Exposed = False" This means it is not in the TLB or exposed outside of the VB6 DLL, but can still be passed methods exposed over COM expecting the .Net interface (and that is all we really needed anyway). This fixed the symptom (the error goes away!), but definitely didn't fix the root problem addressed in my question since this solution might not work for everyone. – Synder

Fair enough, asking out of pure curiosity, thanks for the reply! – Collins

are you sure, that this is the best way? I suggest you to evaluate what that activeX does on vb6 and search the best way to do it on vb.net. In example you could find that on vb.net the function is included. I hate portings, the most of the times it is faster to rewrite it. – Granados

Answer 1

The Visual Studio IDE definately takes a different path when registering DLLs for COM Interop then it does when running the command line tools from a command prompt.

I doubt that Microsoft has documented this anywhere. However, my years of experience have proven this to be the case. I once ran into a situation in which a "regsvcs" command from the .NET 2.0 Framework would actually cause an infinite loop. If you Google it you'll probably find others that have had this problem. I was able to make it one step further by using the VS IDE to perform the COM registration of a .NET Serviced Component. However, it inevitably ended in error. The error was a step forward over the infinite loop. Either way it proved to me that the VS IDE takes a different code path / business logic when dealing with COM Interop and registry entries.

Beaner

It does. It won't import the TLB if there are any warnings. The kind of warnings that Tlbimp.exe displays on the console and can often be ignored because they are benign. Give or take. – Mistrial