我有一个可以安装在Windows(XP / Vista / 7)上的驱动程序。它是通过第三方应用程序链接到的本机C ++ DLL访问的,也是Winsock Provider(WSP)。它过去是在System32下安装的,但是看过不建议,我把它改为在ProgramFiles下安装。
现在,问题是人们不得不将其复制回System32,或者只要他们想在自己的应用程序中使用它就将其复制到应用程序目录中,因为Windows不会在ProgramFiles下搜索安装目录。应用程序尝试加载DLL。
我一直无法找到任何讨论此问题的Microsoft文档,因此如果不应该使用System32,那么应该在哪里安装共享DLL?
答案 0 :(得分:7)
Windows并排缓存。 Backgrounder信息is here,技术参考is here。
除了微软之外,我还没有看到任何人真正这样做过。值得注意的是,MSFT放弃了针对VS2010的C / C ++ CRT和MFC运行时DLL的winsxs部署,这导致了太多问题。他们回到了c:\ windows \ system32。虽然这个(GAC)的管理等价物很强大。可能更好的工具支持。
我很确定每个人都会选择应用本地部署。
答案 1 :(得分:5)
因为它是一个链接到你的驱动程序的DLL可能它不是一个问题,但我要小心尝试共享DLL,而是试图让所有客户端应用程序开发人员保持自己的dll版本他们的应用文件夹 我在DLL Hell中有太多的乐趣想要更多奇怪的错误,因为AppX用旧的版本覆盖了AppY等旧版本。
答案 2 :(得分:2)
路上的任何地方都可行 如果这只是与你的一组应用程序(例如Qt4.dll)一起使用,那么在“c:\ program files \ my company”的根目录中会很好,或者在下面有一个“共享”文件夹。
如果它被其他您不了解的应用程序(例如视频编解码器)使用,那么system32是有意义的(安装时需要管理员权限)
答案 3 :(得分:2)
一种可能性是将它们安装在Program Files
的子目录中,正如@Martin Beckett所建议的那样。
如果您不想在固定位置安装它们,您还可以将它们的位置存储在Windows注册表中。您可以在HKEY_LOCAL_MACHINE\SOFTWARE
下安装一些应用程序可以读取的密钥,以找出DLL所在的位置。然后可以在运行时加载DLL。
您可以更进一步,使用注册表或其他一些存储(比如文件)来存储有关哪些应用程序使用哪个DLL的信息。例如:
FooCommon.dll <- FooApp1, FooApp2, FooApp3
FooBar.dll <- FooApp1, FooApp3
FooBaz.dll <- FooApp2, FooApp3
每当您的某个应用程序未安装时,它就会从此地图中删除。然后,任何卸载程序都可以安全地删除任何应用程序不再使用的DLL。该方法类似于引用计数,其目的是防止孤立的DLL累积在用户的文件系统上。
答案 4 :(得分:1)
原生DLL可以存储为并排程序集。有关详细信息,请参阅this reference。这与.NET全局程序集缓存分开,但它使用类似的概念。这个blog post还有很多关于DLL如何作为并排程序集解析的有用细节。