由插件引用的DLL的搜索路径
我正在用本地C ++编写一个Windows应用程序插件(作为一个DLL)。 我们称之为myplugin.dll
。 我的插件引用另一个DLL,我们将其称为other.dll
。
我的插件安装在应用程序plugins
目录的myplugin
子目录中:
application.exe
plugins
myplugin
myplugin.dll
myplugin.dll
隐式链接到other.dll
。 我不能延迟加载other.dll
因为它暴露了虚拟方法的类,虚拟方法表被视为数据,它们不能从延迟加载的DLL中导入。
我自然会喜欢的地方other.dll
在pluginsmyplugin
目录中,旁边myplugin.dll
,但默认情况下,Windows将不会看在pluginsmyplugin
搜索时other.dll
(源)。
除了将other.dll
放在应用程序的根目录之外,我的选择是什么?
(虽然修改静态链接DLL的DLL搜索路径的问题是相关的,但它描述了一个不太合理的场景:一个应用程序隐式链接到一个插件DLL。我相信一个清晰的典型场景可能有助于发现额外的这个常见问题的解决方案,比如当应用程序加载myplugin.dll
时显式加载other.dll
,如果可能的话)。
编辑:另一个类似的问题:依赖于其他DLL的插件DLL
编辑:我找到了问题的解决方案,请参阅下面的接受答案。 据我所知,这是最干净的解决方案。 我希望它能帮助别人。
我在对我的问题的最后评论中概述的想法非常好。
我将myplugin.dll
更改为简单的shim DLL。 该垫片的入口点执行以下操作:
pluginsmyplugin
目录中加载other.dll
(使用LoadLibrary
)。 myplugin-impl.dll
,即“真正的”插件。 myplugin.dll
然后简单地将所有调用转发给myplugin-impl.dll
,它执行实际的工作。
请注意, myplugin-impl.dll
仍隐式链接到other.dll
。 但是,当加载myplugin-impl.dll
时,其他other.dll
已由应用程序进程的地址空间中的填充程序加载,因此不会再发生进一步的加载。
有了这个解决方案,我们可以获得隐式DLL加载的好处(特别是使用虚拟方法加载C ++类),同时仍然可以完全控制加载隐式加载的DLL的位置以及它的加载方式。
链接地址: http://www.djcxy.com/p/44503.html上一篇: Search path for a DLL referenced by a plug
下一篇: What becomes the search path of a .dll loaded with System.loadLibrary() in java?