通过反射从Interop程序集查找源DLL名称 [英] Finding the source DLL name from Interop assembly via reflection

问题描述

我有一个Interop DLL RCW.Xyz.dll，但找不到相应的DLL.因为名称不遵循默认的命名方案Interop.Xyz.dll，所以我猜想互操作程序集只是被重命名了. (即使DLL是使用默认名称由Visual Studio生成的，如果DLL的名称中包含空格，空格也会丢失，从而使得很难再次找到源DLL)

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)

如何找到互操作程序集后面的COM DLL名称?

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

我认为我需要使用拆卸工具.最好是，我正在寻找一种可以在 dotPeek 中使用的解决方案，因为我没有Reflector许可证.

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.

推荐答案

COM互操作不一定为一个COM库创建一个互操作库.这只是类型库导入程序的默认行为.也可以为多个COM库提供一个互操作程序集，或者为一个COM库提供多个互操作程序集.

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.

互操作程序集甚至都没有链接到COM库！无需在目标系统上安装源库即可轻松部署它.实际上，一旦您尝试创建这些库对象之一的实例，它就会失败.当您想要找到它们的源时，互操作程序集内的对象很重要.它们称为运行时可调用包装器(运行时表示CLR).这就是为什么您的互操作程序集被称为RCW.Xyz.dll的原因.程序集的开发人员可能使用了tlbimp的/out开关来创建它.

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.

当您要搜索库时，在其中定义了某种COM类型，只需在interop程序集内找到类名即可.您可以使用Visual Studio的对象资源管理器来执行此操作-无需反汇编interop程序集.这些程序集通常根本不定义任何代码.它们仅提供满足CLR的元数据.每个类都标记有ComImport属性和Guid属性.使用此GUID标识注册表中的类(如您在回答中提到的HKEY_CLASSES_ROOT\CLSID\{GUID}). Inproc32键的默认值是在其中定义类型的库.请注意，这仅适用于Inproc COM服务器(DLL； COM als支持其他库类型).

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).

如上所述，实际上必须对每个类都这样做.但是，如果互操作程序集的开发人员使用类型库导入程序生成了互操作程序集，而没有修改或与其他程序合并，则由于tlbimp的默认行为(如前所述)，仅对一种类型的操作就足够了.

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.

这篇关于通过反射从Interop程序集查找源DLL名称的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！