Finding the source DLL name from Interop assembly via reflection

Question

I have an Interop DLL RCW.Xyz.dll but I can't find the corresponding DLL. Because the name doesn't follow the default naming scheme Interop.Xyz.dll my guess is that the interop assembly was simply renamed. (Even if the DLL is generated by Visual Studio with a default name, if the DLL has spaces in its name, the spaces will get lost, making it hard to find the source DLL again)

How can I find out the COM DLL name behind the interop assembly?

I assume I need to use disassembly tools. Preferably I'm looking for a solution which works in dotPeek as I don't own a Reflector license.

Answer 1

COM interop does not necessarily create one interop library for one COM library. This is only the default behaviour of the type library importer. It is also possible to provide one interop assembly for multiple COM libraries or multiple interop assemblies for one COM library.

An interop assembly is not even linked to an COM library! It can be easily deployed without the source library installed on the target system. In fact, it will fail as soon as you are trying to create an instance of one of the libraries objects. The objects inside an interop assembly are important when you want to find their source. They are called Runtime Callable Wrappers (Runtime stands for the CLR). That's the reason why your interop assembly is called RCW.Xyz.dll. Propably the developer of the assembly used tlbimp's /out switch to create it.

When you want to search for the library, a certain COM type is defined in, just find the class name inside the interop assembly. You can use Visual Studio's object explorer to do this - no need to dissassemble the interop assembly. Those assemblies usually do not define any code at all. They only provide metadata to satisfy the CLR. Each class is marked with a ComImport attribute and a Guid attribute. Use this GUID to identify the class inside your registry (HKEY_CLASSES_ROOT\CLSID\{GUID} as you mentioned in your answer). The Inproc32 key's default value is the library the type is defined in. Note that this only applies to inproc COM servers (DLL's; COM als supports other library types).

As mentioned above, this must actually be done for each class. However, if the developer of the interop assembly used the type library importer to generate the interop assembly and did not modify or merge it with others, it should be enought to do it only for one type, because of tlbimp's default behaviour, mentioned earlier.

Answer 2

If the DLL is installed, these are the steps:

• Open the interop assembly in dotPeek
• Find the CCOMActivatorClass class and disassemble it
• Look at the [Guid] attribute of CCOMActivatorClass
• Open regedit.exe and navigate to HKEY_CLASSES_ROOT\CLSID\{GUID}\InprocServer32
• The default value should point to the DLL