确定我的程序实际使用了哪些DLL和/或OCX文件？ [英] Determine which DLL and/or OCX files are actually used by my program?

问题描述

我的软件是用VB6编写的。为了进行诊断，我需要确定应用程序在客户计算机上加载和使用的实际DLL / OCX文件。

My software is written in VB6. For diagnostic purposes I need to determine the actual DLL / OCX files which are loaded and used by the application on a customer's computer.

由于VB6 DLL（包括OCX文件）是它们是根据注册表中的信息间接加载的COM库。这意味着使用的文件可能不同于开发/测试环境中使用的文件。有时在客户端环境中，这可能会导致故障，如果没有这些信息就很难诊断。

Since VB6 DLLs (including OCX files) are COM libraries they are loaded indirectly based on information in the registry. This means it is possible that a different file is being used than what was used in development / testing environments. Sometimes in a client environment this can cause malfunctions which are hard to diagnose without this information.

（我的计划是在程序中建立一个显示数据库的诊断读取窗口

(My plan is to build a diagnostic readout window in my program that shows the libraries that the program is using at that moment.)

推荐答案

在运行时依赖DLL（或OCX文件）的方式有很多可以建立。理想情况下，您需要考虑所有这些因素：

There are many ways in which runtime dependencies on DLLs (or OCX files) can be established. Ideally you would need to account for all of them:

此答案特定于VB6，但是许多其他编程语言也可以类似地工作。

This answer is specific to VB6 but many other programming languages would work similarly.

建立运行时相关性的机制：

Mechanisms which establish runtime dependencies:

在编译时，传统的动态链接库（不是COM的DLL）

At Compile time for traditional dynamically-linked libraries (DLLs which are not COM)

• 文件（顾名思义）根据链接过程在运行时动态加载在编译结束时完成


• 这包括使用如下语句的VB6代码： Declare Function…Lib…


• （在.NET中，这意味着调用本机代码）


• 要识别：检查源代码。


• 要识别没有来源：诸如Dependency Walker之类的工具可以检测到这些来源

• Files are (as their name suggests) dynamically loaded at runtime based on the linking process done at the end of compilation
• This includes VB6 code which has used a statement like: Declare Function … Lib …
• (In .NET this would mean calling out into "native code")
• To identify: Inspect the source code.
• To identify without sources: These can be detected by a tool like Dependency Walker

在编译COM DLL时

• 在VB6中，这称为早期


• 这包括VB6代码，该代码已显式设置对DLL或OCX的引用。


• 请注意，该依赖关系实际上是在COM类或接口GUID上，而不是在DLL文件本身上。


• ：这些列在项目VBP中。


• 标识（备用）：如果您没有VBP或源代码，通常可以通过揭示这些依赖关系OLEView中的IMPORT 语句。您可能需要在注册表中从那里查找一些GUID，以查看实际使用的DLL文件。

• In VB6 this is known as "early binding".
• This includes VB6 code which has explicitly set a reference to a DLL or OCX.
• Note that the dependency is actually on the COM class or interface GUID, and not explicitly on the DLL file itself.
• To identify: These are listed in the project VBP.
• To identify (alternate): If you don't have the VBP or source code, these dependencies can generally be revealed by by IMPORT statements in OLEView. You might need to look up some GUIDs from there in the registry to see what actual DLL files are used.

在编译时静态链接库的时间（不是COM，不是DLL）

At Compile time for statically-linked libraries (not COM, not DLLs)

• 库代码包含在EXE或DLL中，正在编译。因此，没有任何外部依赖于运行时。


• 据我所知，这对于VB6程序是不可能的。诸如C链接器之类的东西可以使用这样的库。 .NET中的大致等效项将使用ILMerge组合程序集。

• Library code is included in the EXE or DLL which is being compiled. Therefore there is no runtime dependency to anything external.
• As far as I am aware, this is not possible for VB6 programs. Something like a C linker could use libraries like this. A rough equivalent in .NET would be using ILMerge to combine assemblies.

在运行时，传统DLL（不是COM）

• 可以使用Win32 API任意加载DLL，例如 LoadLibrary（）。


• 要识别：您必须查看消息源以了解可能发生的情况。


• 或者，如果您没有源代码，则可以使用诸如Process Explorer和/或Process Monitor之类的工具来观察正在运行的实例，并查看实际加载了哪些DLL。

• DLLs can be loaded arbitrarily using Win32 API such as LoadLibrary().
• To identify: You have to look at the source to know what might happen.
• Alternately if you don't have the source you could use tools like Process Explorer and/or Process Monitor to observe a running instance and see what DLLs actually get loaded.

在运行时用于COM DLL

• 可以任意加载类使用例如VB6 CreateObject（）调用。


• 在VB6中，这被称为后期绑定


• 将使用哪个DLL提供的类将由进程的激活上下文确定。激活上下文是由应用清单文件（如果有）或Windows注册表（VB6程序的默认默认设置）建立的。


• 用于标识：您必须查看源以了解可能发生的情况。您还需要知道运行代码的PC上的配置状态-假设未使用清单，哪些DLL文件已注册。


• 无源的替代方法代码：如上例

• Classes can be loaded arbitrarily using eg VB6 CreateObject() calls.
• In VB6 this is known as "late binding"
• Which DLL will be used to provide the class will be determined by the process’s activation context. The activation context is established by the app manifest file (if there is one) or the Windows registry otherwise (the normal default for VB6 programs).
• To identify: You have to look at the source to know what might happen. You also need to know what the configuration state will be on the PC that runs the code - which DLL files are registered, assuming a manifest is not used.
• Alternative for no source code: as in the case above

重要提示：依赖关系可以被链接。因此，实际上，您需要遍历所有依赖项的链接，直到建立所需内容的完整映射。在该映射中的某个位置，您可以在需要部署的内容与可以依靠其提供的操作系统或其他运行时环境之间划清界限。 （IMO对于VB6，应该相当宽泛地划出界线。）

Important: dependencies can be chained. So really you need to "walk the links" of all the dependencies until you build up a complete mapping of what is required. Somewhere in that mapping you can draw a line between what you need to deploy and what the operating system or other runtime environment can be relied on to provide. (IMO for VB6, that line should be drawn rather liberally).

您可能会以为所有这些使任务完成非常困难或乏味–我完全同意。 ：）

You may be thinking that all this makes the task very difficult or tedious – I totally agree. :)

这篇关于确定我的程序实际使用了哪些DLL和/或OCX文件？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！