1

We're integrating a communications company's software into our own for doing things like answering calls, transfering calls, matching numbers with clients etc.

They have given us the API documentation, which includes a TLB file. We've used the tlbimp tool to create an assembly which we now want to use in our implementation.

Some of the classes created by tlbimp have been given internal constructors, rendering them uninstantiable. I think it should be ok in this instance as another class should return an instance of these classes.

This made me think though: are there any other pitfalls I should be aware of when using tlbimp.exe, and TLB's as a whole? Would it be better to create the DllImport/ComImport/PInvoke code by hand?

VividD
  • 10,456
  • 6
  • 64
  • 111
CarllDev
  • 1,294
  • 2
  • 19
  • 34

2 Answers2

2

In general if you have a TLB I would at least start my work by consuming the assembly produced by tlbimp.

The tool itself is widely used and produces correct code based on the definitions provided in the TLB. I have seen some circumstances where the resulting code was incorrect but it almost always came back to either a very complex marshalling situation with arrays or a place where the TLB author had simply added the wrong COM annotations.

If you do find any issues down the road then you should consider beginning to hand code the fixes. But I certainly wouldn't start that way.

JaredPar
  • 733,204
  • 149
  • 1,241
  • 1,454
2

You cannot pinvoke the kind of COM interface methods that are declared in a type library. The DLL that implements the COM server doesn't export the methods. You can use late binding with reflection or the dynamic keyword but that's painful and error prone. Use the import library, that's why it is there.

Hans Passant
  • 922,412
  • 146
  • 1,693
  • 2,536