Int*_*oet 8 dll search winapi path
我们的产品包括几个从开源构建到文件中的DLL,默认名称由开源开发人员提供.我们小心地将文件安装在我们自己的目录中,并且我们仔细管理搜索路径(仅针对我们的进程)以保持加载器满意.
另一个开发人员 - 一个高耸的智慧 - 决定在相同的默认DLL文件名下安装他们自己的一些相同开源的构建到C:\ WINDOWS会更容易.因此,当我们启动依赖于这些开源DLL的进程时,系统会在我们的目录之前搜索C:\ WINDOWS并找到其他开发人员安装的DLL.当然,它们是不相容的.
到目前为止我发现过的想法:
由于各种原因,目前这些选项都不合适.
我们还能做些什么来保护自己免受世界高耸的智慧的影响？
您只有两个选项:将DLL部署在与EXE相同的目录中(这是Windows首先查找的位置)或使用清单并将DLL部署到Windows并行缓存.我不认为后一种选择在开源世界中很常见,但如果你想在不同的应用程序之间共享DLL,它是唯一真正的修复.
要添加已经很好的答案，您还有更多选择：
此问题的首选解决方案（从 Windows XP 开始支持）是将 dll 转换为 win32 程序集（它们不必是 .NET，但有关使用强名称创建 win32 程序集的文档非常简单，因此很容易感到困惑并认为这是仅限 .NET 的技术）。
程序集比包含 dll 的文件夹（包含程序集的名称）和包含 assemblyIdentiy 元素的 .manifest（包含程序集的名称）以及程序集中每个 dll 的多个文件节点更复杂。
即使 dll 是静态链接的，基于程序集的搜索也能工作！
如果 exe 位于不同的文件夹中，则有两种方法可以访问共享程序集：
如果您希望应用程序在 Windows 7 及更高版本上使用，则可以将程序集存储在私有备用位置。为每个 exe 创建一个 app.exe.config 文件，并将探测 privatePath元素指向存储程序集的公共文件夹。
如果您同意需要管理访问权限来执行安装（通过 MSI），那么您可以处理极其糟糕的文档（好吧，缺少文档），这些文档涉及为程序集提供强名称，然后将程序集存储在 WinSxS 中。
如果您不能或不想将 dll 捆绑为程序集，则此页面涵盖了 dll 搜索顺序
使用像SetDllDirectory这样的函数只会对在运行时动态加载的 dll 有帮助（通过 LoadLibrary）。
DLL 搜索顺序曾经是：
您可以利用它来发挥您的优势 - 启动每个 exe，将“当前”目录设置为包含 OSS dll 的文件夹。
随着 SafeDllSearchMode 的出现，现在的搜索顺序是：
这意味着现在的控制比以往更少:( - 它会更快地进入“不受信任的”c:\windows 和 System32 文件夹。
同样，如果初始 dll 是通过 LoadLibrary 加载的，并且其依赖的 dll 是问题所在，则带有 LOAD_WITH_ALTERED_SEARCH_PATH 标志的 LoadLibraryEx 将导致以下搜索顺序（假设您将完整路径传递给 LoadLibraryEx）：-