How is Interop.xxxxx.dll generated?

Question

I recently took over a project and have little VS COM experience so please forgive me if I am not asking the right questions..

I have a C++ project which generate a COM dll, lets name it abc.dll.

I have another C# project which references the COM dll, however under the references, it is pointing to Interop.abc.dll. I deleted all abc.dll within the directory and interrop.abc.dll to see how the project would react, upon starting the project, interop.abc.dll is automatically generated. This boggles my mind because I dont know how interop.abc.dll is generated.

So here are my questions:

1. How does the C# project reference the interop.abc.dll initially if this is generated?

2. How is the interop.abc.dll generated if there is no abc.dll to begin with (I havnt built it)

3. I played around with the project and then interop.abc.dll stopped generating and was causing errors, why is it?

Answer 1

COM declarations are stored in a type library. Which is very similar to .NET metadata, COM was the grand-father of .NET, metadata that tells a compiler what types are stored in an assembly. Type libraries however use a fairly awkward binary format, it is very different from .NET metadata. Different enough to make the conversion from a type library to .NET metadata non-trivial. Some constructs have no conversion at all, some are troublesome enough that you ought to know about it.

So the .NET team decided that the conversion should be a separate step, one that could display warnings, or errors, when the type library content doesn't match .NET metadata closely enough. That conversion tool is Tlbimp.exe, the type library import tool. They did add this feature to the Project + Add Reference dialog. As long as the conversion doesn't generate any warnings that this works just fine. It very often does.

So the job of Tlbimp.exe, and the IDE in the case of Add Reference, is to mechanically translate the type library content to .NET metadata content. By convention, a type library named "Foo" is converted to "Interop.Foo.dll". It doesn't have to be, just the default name. You'll end up with a .NET assembly that doesn't contain any code, just metadata. .NET types that any .NET compiler can directly consume and otherwise match the type library declarations. The [ComImport] attribute is a very important one that tells the CLR that the metadata is actually for COM types.

So this all explains bullet 1. Bullet 2 is a no-go, you really do need the type library. It is very often embedded as a resource in the unmanaged DLL, Tlbimp.exe knows how to find it. Nobody can see the errors in 3 so of course it is unguessable what the problem might be. Just keep in mind that the conversion is not always without trouble, the point of making the conversion step explicit.