确定我的程序实际使用了哪些 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 中，这称为早期绑定".
• 这包括明确设置了对 DLL 或 OCX 的引用的 VB6 代码.
• 请注意，依赖关系实际上是在 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)在运行时

• 可以使用LoadLibrary()等Win32 API任意加载DLL.
• 要识别:您必须查看来源才能知道可能发生的情况.
• 或者，如果您没有源代码，您可以使用 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

重要提示:可以链接依赖项.因此，您确实需要遍历所有依赖项的链接"，直到您建立所需内容的完整映射.在该映射中的某处，您可以在需要部署的内容与可以依赖操作系统或其他运行时环境提供的内容之间划清界限.(对于 VB6 的 IMO，这条线应该画得相当宽松).

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屋！