4

I have a .tlb file, which exposes, via COM, functions of a C# DLL. I wish to load this .tlb at runtime and use the functions within my native project.

While I can load the library by using LoadTypeLib function, I am not sure how the ITypeLib returned helps me in using the functions within the .NET DLL. With a regular DLL, I could have used GetProcAddress with the DLL handle and obtain the function address, but I don't suppose it will work with a type library?

How, then, should this be approached?

VividD
  • 10,456
  • 6
  • 64
  • 111
user1173240
  • 1,455
  • 2
  • 23
  • 50
  • Are you wanting to do this at runtime e.g. if you are creating a scripting language binding? Or do you just want to do this at compile time and be able to use the objects at runtime? – Ben Aug 28 '15 at 16:19
  • I wish to see if a `tlb` is present, and then use the objects within it, i.e., the decision to use the COM objects within it needs to be made at runtime. I wish to avoid using `#import` for the `tlb` which I suppose is the standard way of using one. – user1173240 Aug 28 '15 at 16:22
  • Right, but do you need to use different COM objects e.g. created later, or is the set of COM objects you are going to use known at compile time? – Ben Aug 28 '15 at 16:23
  • By COM object, I suppose you mean the .NET interface I had exported with the .tlb? If so, yes, I know those at compile time. I will be aware of the function names and the interface name at compile time. – user1173240 Aug 28 '15 at 16:26
  • 1
    Then I would use `#import` - it is by far the easiest way. You only need to use a type library at runtime if you don't know the types in advance. If you just want to check that the DLL exists (e.g. if it is an optional component or separately licensed plugin) then you can do that using any reasonable method, including trying to create the object and catching any exception. – Ben Aug 28 '15 at 16:28
  • So, I should first check whether the `.NET DLL ` actually exists, and then take a decision to import the `tlb`? But in this case, how will the compiler recognize the namespace and the interface names, which have been used? – user1173240 Aug 28 '15 at 16:36
  • Let us [continue this discussion in chat](http://chat.stackoverflow.com/rooms/88227/discussion-between-ben-and-user1173240). – Ben Aug 28 '15 at 16:44
  • Thank you for your help on this. If you move this as an answer, I would mark it as one. – user1173240 Aug 28 '15 at 17:31
  • Why on Earth was this down voted? – user1173240 Aug 28 '15 at 18:04

1 Answers1

6

A type library does not contain any code, it contains a description of the API and the objects, functions and other types exposed by that API. It can describe a standard DLL and its functions, and it can also describe COM objects, some of which may be directly createable, others which may be obtained from other functions or objects. But it only contains a description.

Generally, a TLB is only needed at compile time, so the compiler can know the types of the objects and generate the correct code to call them. You don't need it any more at runtime.

In this way it is analogous to a header file. Indeed, using #import actually generates a header file automatically (look in your build directory to see it), and this header file is all that is actually required to compile your application. So a type library is (more or less) equivalent to a binary format header file for a COM DLL.

At runtime, the header file is not required, and nor is the type library. To conditionally use objects depending on whether they are installed, you do this in essentially the same way as for any other DLL. I.e. you look to see if the DLL is installed, and if not, you don't attempt to use the DLL code.

For COM objects it can be simpler. Attempt to create one of the objects, and if you fail with REGDB_E_CLASSNOTREG then that means the DLL is not installed (or not registered properly).

Ben
  • 34,935
  • 6
  • 74
  • 113