我有一个正在开发的 SDK，而之前的开发人员刚刚在 System32 中删除了 DLL（显然是严重的冒犯：see here）
因此，假设我将它们移出到 \Program Files\\SDK（或其他），我如何确保所有需要这些 DLL 的应用程序都可以访问它们？澄清一下，所有访问这些的应用程序都在编译时对 DLL 进行早期（静态）绑定，因此我无法将完整路径传递给它们或任何东西。他们需要能够在仅给出 DLL 文件名的情况下找到它。
同样，包含特定版本的 MSVCR80.dll 怎么样？他们都依赖于此，但我需要确保他们获得特定版本（我包含的版本）。 有什么想法吗？
【问题讨论】：
我无法告诉您您自己的 DLL，但您应该永远单独重新分发 Microsoft DLL。
您始终必须使用 Microsoft Redistributable Package。
例如，如果您的应用程序依赖于 Dev Studio 2005 SP1 中的 dll，您应该使用 Microsoft Visual Studio 2005 SP1 可再发行组件重新分发您的应用程序。这同样适用于 2008。MS 提供基于 MSI 的安装程序和合并模块以包含在您自己的产品安装程序中。
【讨论】：
如果您无法将 dll 安装到与使用它们的 exe 相同的目录中，您可以将您的目录附加到 PATH 环境变量中。
你没有说你使用的是哪个版本的 Windows，因为细节与我记得的略有不同。
您也可以将您的 MSVCR80.dll 版本放在同一个文件夹中。但是，您必须确保您的文件夹在路径上的系统文件夹之前，否则链接器将首先选择“标准”文件夹。但是，如果您采用“本地”dll 方法，则不会出现此问题，因为 Windows 会首先搜索本地目录，因此会选择您的 MSVCR80.dll 版本。
您的版本是最新版本还是旧版本？您最好让您的应用程序使用该版本或更高版本，然后允许用户根据需要更新他们的机器。这也说明了为什么您永远不应该弄乱 \Windows 或 \Windows\system32 中的 dll，因为正如其他人所指出的那样，您可以通过更改此 dll 的版本来破坏其他应用程序。
【讨论】：
根据定义，SDK 是一个开发工具包。不是部署补丁...
这意味着依赖于这些程序集的应用程序应该随它们一起提供并将它们安装到它们的本地 \program 文件.. 目录中。
这样做的原因是假设您决定通过消除一个入口点来进行重大更改。通过安装“SDK”，它有可能阻止旧程序运行。
您可以参考 Java 手册并更新 PATH 环境变量。每当程序调用外部程序集时，它都会沿着该环境变量搜索，直到找到它。
当然，这仍然可能导致问题出现。因此，最好的办法是将 SDK 安装到 Program Files 中，让依赖于您的工具包的产品开发人员决定是否要更新其版本。
更新
正如我正在考虑的那样，最后一种可能性是 GAC 您的程序集。如果您这样做，请记住，它们应该被强烈命名并正确版本化，以免相互踩踏。我不推荐这条路线，因为它隐藏了程序集的实际位置，并且使卸载更加困难，然后只需在您的目录上点击删除。
【讨论】：
您问的是“DLL Hell”，我认为每个 Windows 开发人员都很熟悉。查找DLL的顺序为：
由于应排除 Windows 目录，因此您有三个选择。
【讨论】：
您可以将安装路径放在搜索路径中，这样应用程序就可以找到它们。
或者，您可以将 DLL 部署到与依赖它们的应用程序相同的目录中。
我相信从 SDK 的角度来看，第一个更好 - 它会使开发更容易。但我认为第二个更适合将应用程序部署到最终用户，除非您预计单个系统上可能有许多消费者，因此拥有 DLL 副本的磁盘和内存占用量是令人望而却步的。
【讨论】：