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