InstallShield UseDLL() 在同一目录中找不到 dll 依赖项答案

【问题标题】：InstallShield UseDLL() doesn't find dll dependencies in the same directoryInstallShield UseDLL() 在同一目录中找不到 dll 依赖项
【发布时间】：2019-03-17 13:04:50
【问题描述】：

我有 1 个 dll 文件，我尝试在安装过程中使用我的一个安装脚本中的 UseDLL() 加载该文件。这个 dll 有 2 个它依赖的 dll。它们都位于主 dll 的同一目录中。

在使用较旧的 installshield 构建安装时 - 它发现它的依赖项并且工作正常。当我尝试使用 IS2016 构建它时，它失败了，因为它没有找到它的依赖项。（如果我将这 2 个 dll 放入 SysWOW64 - 它会找到它们并且工作正常）。

有什么问题？

谢谢，嘟嘟

【问题讨论】：

标签： dll dependencies installshield installscript

【解决方案1】：

通过名为 DLL_DIRECTORY_SUPPORTDIR 的新启用/禁用标志，它看起来像 InstallShield 2018 makes this easier。但是在 InstallShield 2016 中，您很有可能可以添加以下 InstallScript 代码来查找 SUPPORTDIR 中的依赖项。如果您的 DLL 位于不同的目录中，请替换它。

// Add prototype for SetDllDirectory(); this typically goes near the top of your script
prototype number kernel32.SetDllDirectoryW(wstring);

// Call it; this goes in a function called before your UseDLL call
SetDllDirectoryW(SUPPORTDIR);

请注意，这样做会删除一些防止 DLL 植入的保护，因此只有在确保相关 DLL 主动抵抗此类事情，或者您审查并保护相关目录时，这样做才是最安全的。（我不确定 InstallShield 是否会为您执行此操作。）

【讨论】：

谢谢，它有效！虽然我不明白为什么会在 IS2016 中发生这种情况，因为他们提到更改是在 IS2018 中完成的。
“SetDllDirectoryW”是否作为相反的功能？所以我可以在完成安装后从 dll 搜索路径中删除 SUPPORTDIR 吗？谢谢！
为了澄清，在 2018 年添加了启用/禁用选项；这些保护是在 2016 年添加的，可作为早期版本的热修复程序使用。微软SetDllDirectoryW 的文档解释了如何反转事情，但我不记得你是否可以控制在 InstallScript 中传递 NULL 和空字符串。