Question

好的，所以我已经为我的可执行文件的插件成功设置了我的Private Assembly，例如described here：_{（这只是一个例子，我的用例在技术上是相同的，但是不适用于插件。）}

可执行文件使用应用程序清单在dependentAssembly程序集

plugins

plugins子目录包含plugins.manifest
plugins.manifest声明assemblyIdentity，其中files列出了插件DLL（例如，easyplug1.dll和xplug2.dll）

我还没有找到任何直接解释，私有程序集中的DLL所依赖的DLL 是什么？它们应该放在哪里，它们是如何找到的？

示例：xplug2.dll，是第三方本身需要第三方dll xbase.dll。当然，xbase.dll也只是部署在plugins目录中。这够了吗？ 私有程序集是否需要列出仅由（可执行）模块传递使用的DLL，声明其对plugins程序集的依赖性？

到目前为止通过反复试验获得部分答案：

（A）似乎所有 DLL，也只能在其他“插件”DLL中使用的那些DLL必须列在私有程序集清单中 - 即基本上应列出所有 plugins程序集目录中的DLL文件。

（A.1）目录中找不到任何未列出的，即使它是从同一子目录中的DLL引用的。

（A.2）我假设这是由于所有DLL加载机制都使用来自可执行文件的（仅）自定义Activation Context，并且如果在那里找不到DLL ，它似乎从可执行文件目录中搜索。

（A.3）我尝试用the latest version Dependency Walker（2.2.10011）查看依赖关系链，但似乎根本无法处理这种传递场景：主要依赖关系是显示正确，但传递的辅助依赖项不是从清单解析，而是相对于基本目录。（对于plain LoadLibrary semantics）

，似乎the transient ones.

文件布局：

...\base\app.exe 
    // - contains Application Manifest declaring dependency on `plugins`
    // - Loads xplug2.dll

...\base\plugins\xplug2.dll
    // - Loads xbase.dll (which is only used by xplug2.dll internally)

...\base\plugins\xbase.dll

...\base\plugins\plugins.manifest
    // - lists xplug2.dll (for sure)
    // - *seems* to need to list also xbase.dll

Answer 1

简单的答案是，将使用应用程序激活上下文和/或默认dll搜索规则搜索不属于程序集的任何“原始”dll。并且dll搜索路径包括应用程序文件夹，但没有找到dll的任何文件夹（即dll永远不会期望加载另一个偶然在同一文件夹中的dll。）

因此，例如，如果程序集中的dll需要openssl.dll，那么它将首先在application.exe的文件夹中搜索，而不是私有程序集文件夹，除非您明确地将openssl添加到私有程序集中。 / p>

答案是明确地将openssl.dll添加到私有程序集（如果不同的dll - 在不同的程序集中 - 需要不同版本的openssl.dll，则顺便帮助保护应用程序的完整性）

在您的情况下，您可能有两个不同的私有程序集，每个程序集使用私有版本的xbase.dll - 其中两个不同的xbase.dll可能非常不兼容。

私有程序集和传递DLL依赖项？

1 个答案: