I'm in a peculiar situation now -
I've got to integrate my product X (name not disclosed) with another product Y (you might know about it, but I dont want to attract attention). The guys in charge of product Y gave me a type library (tlb) so that I could integrate X with Y using COM interop in .Net .
I could have done it in any MS automation supported language, but my product is an RIA deployed using ClickOnce, hence I did the COM interop using C#. The tlb is for a dll that is shipped with product Y (and not my product X), and it is provided by the developers of Y seperately on request (it's the same tlb whether the integration is to be done in vb, vb.net vbscript or any other language).
And to successfully deploy the integrated product, I will have to write a separate installer (outside ClickOnce) that will register the type library that they've provided.
The funny part is that the type library information is not present in the dll, and one has to go through a seemingly infinite loop to eventually get the tlb, and then write a separate installer to do what the installer for product Y should have done.

Is this just me or is everyone thinking what these chaps at company Y are doing? Isnt it stupid to separate the type library (y) from the COM component (Y) and then register the component using the installer of Y and register the type library using installer of X ? And then there are the issues of the component itself being rewritten by Y , type library being changed by Y...

Arrhh. I feel like kicking the brains of the lawyer who's behind all this.
But no point. My boss will still think that the chaps at Y are "Brillant". Bleh.

Type libraries make it simpler to instantiate across different language environments its not really anything to do with installing. 

I'd expect any third party component dll to register itself though.

Yea, that's what I expected.
But in this case, the dll doesnt come with the type library; and hence despite the dll being registered (I've checked the installer log of the product), the classes and interfaces to enable COM interop are not registered.
The registration of the tlb does that. (In this way, the tlb starts behaving like the COM component and not the dll)
What a bad way to ensure that the developers of Y know who's integrating with their product.