我如何通知独立应用程序相关 DLL 的位置？
我正在编写几个独立的应用程序，它们都依赖于我自己和团队编写的 dll。当我们只有几个 dll 时，一切都很好，但构建输出目录变得相当混乱且难以导航。我最终希望输出构建目录包含以下结构：
- $(OutDir)
- --（应用程序.exe）
- --（应用程序.exe）
- --Libs文件夹
- --(LibA.dll)
- --(LibB.dll)
- （等）
有没有办法让应用程序在运行时使用清单文件之类的东西在“Libs 文件夹”中查找这些库？
I have a couple of isolated applications that I am writing that all rely on dlls that are also written by myself and team. Things were fine when we only had a few dlls but not the build output directory is getting rather cluttered and hard to navigate. I would ultimately like to have the output build directory contain the following structure:
- $(OutDir)
- --(Application.exe)
- --(Application.exe)
- --Libs Folder
- --(LibA.dll)
- --(LibB.dll)
- (etc)
Is there a way to have the applications look in the "Libs Folder" for these libraries at runtime using something like the manifest files?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
动态链接库搜索顺序描述了什么您可能必须修改搜索路径。它描述了搜索顺序并提及清单 和 SetDllDirectory() 具有更改搜索顺序的可能性。
虽然 SetDllDirectory 看起来很有前途，但只有在动态加载 DLL 时它才会可靠地工作，而根据我的理解，您不会这样做。
现在，关于使用清单： 应用程序配置文件 讨论了
privatePath属性，该属性可用于[指定]可能包含程序集的应用程序基目录的子目录的相对路径。在我看来，它似乎只适用于并排装配，但您可能想尝试一下。我承认我从来没有关心过清单（除了在 VS 2005 中你需要知道什么才能让任何东西运行），并且我建议跳过库子目录的想法来隐式加载DLL 并将它们放入应用程序目录中并使用它。对于显式（动态）加载的 DLL，您只需从可执行路径推断出它们的完整路径并将其提供给 LoadLibrary()，也无需费心搜索路径。
Dynamic-Link Library Search Order describes what possibiites you have to modify the search path. It describes the search order and mentions manifests and the SetDllDirectory() function as possibilities of changing the search order.
While SetDllDirectory looks promising, it only will reliably work if you dynamically load your DLLs, which you don't do from what I understand.
Now, as to using manifests: Application Configuration Files talks about a
privatePathattribute that can be used to [specify] the relative paths of subdirectories of the application's base directory that might contain assemblies. It sound to me as if it's only supposed to work for side-by-side assemblies but you may want to give it a try.I will readily admit I have never bothered with manifests (except for what you need to know in VS 2005 to get anything running at all) and I would recommend to skip the idea of the library subdirectories for implicitly loaded DLLs and put them in the app directory and be done with it. For explicitly (dynamically) loaded DLLs, you can just deduce their full path from your executable path and supply that to LoadLibrary() and don't need to bother with the search path either.