Windows 上的 Qt DLL 部署
我有一个来自另一家公司的应用程序的插件。 我的插件使用 Qt，因此需要 Qt DLL。 我的问题是 4.x Qt Dll 的所有版本都被称为相同的，例如：QtCore4.dll。 很可能某些其他插件或将自身插入 PATH 环境变量的另一个应用程序已将 Qt dll 放入应用程序文件夹中。 在这种情况下，插件将不会启动，因为它需要不同版本的 DLL。
- Q1. 建议的 DLL 部署常见做法是什么？
- Q2。 如果主机应用程序使用不同版本的 Qt 该怎么办？ Windows 是否允许主机应用程序和插件使用不同的版本（）？
谢谢！
I have a Plug-in for an application from another company. My plug-in uses Qt so it needs the Qt DLLs. My problem is that all versions of 4.x Qt Dlls are called the same, e.g. :QtCore4.dll. It is quite possible that some other plugin, or another application which inserted itself into the PATH environment variable, has put Qt dlls in the applications folder. In that case, the plug-in will not start as it is expecting a different version of the DLL.
- Q1. What is the suggested common practice for DLL deployment ?
- Q2. What if the host application uses a different version of Qt. Would windows allow the host application and the plug-in to use different versions () ?
Thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
A1：最佳实践：将DLL放在可执行文件的目录中。 它首先会在那里查找以加载 DLL。 这是常见的做法。
A2：如果应用程序以某种方式使用不同版本的 Qt，并且您描述的模块需要更高版本或特定版本，则可能会导致问题（无法工作、崩溃等）。
使用静态链接，您还必须考虑 Qt 的许可证限制。 只要库在运行时动态加载并且可以与应用程序分离，LGPL 就会很高兴。 这仅适用于您不发布源代码等的情况。
此外，您的安装程序应该设置对这些文件的访问权限，以便防止它们被其他恶意应用程序覆盖。
A1: Best practice: put the DLL in the directory of the executable. It will look there first for loading the DLL. This is common practice.
A2: If somehow the application uses a different version of Qt and the module you are describint requires a later or specific version, it might cause a problem (not work, crash, etc).
With static Linking you would also have to consider license restrictions of Qt. LGPL is happy as long as the library is dynamically loaded at runtime and can be separated from the application. This only applies if you do not release your source, etc.
Also, your installer should set up access to those files so that they are protected from being overwritten by some other rogue application.
只是为了帮助其他人解决这个问题：
所有 4.X 版本的 QT DLL 保证相同（或至少二进制兼容）。 （所有 3.X 版本都相同，依此类推）所以不会有问题。 这也是 Qt dll 命名中没有第二个数字的原因。
Just to help others with this problem:
QT DLL's are guaranteed to be the same (or at least binary compatible) for all 4.X Versions. (same for all 3.X Versions and so on) so there will be no Problem. This is also the reason wy there is no second number in the Qt dll naming.
对于 XP 之后的 Windows 版本（即 XP、2003、Vista、2008 和 Win7），您可以使用 并排程序集 或 DLL 重定向。 无论哪种情况，本质上您所做的都是包含一个小文本文件，该文件告诉操作系统您需要使用与可执行文件位于同一目录中的 DLL 的特定版本。
这些是鲜为人知的功能，但它们确实可以将您从“DLL 地狱”中拯救出来。
With versions of Windows since XP (i.e. XP, 2003, Vista, 2008, and Win7), you can use the side-by-side assemblies or DLL redirection. In either case, essentially what you're doing is including a small text file that tells the operating system that you need to use the specific version of the DLLs you included in the same directory as the executable.
These are lesser-known features, but they can really save your butt from "DLL Hell".
没有办法选择与Qt静态链接吗？
我会将 DLL 部署在与我的应用程序/插件相同的目录中。
但这并不能回答您的其他问题。
Is there no way to choose to link statically with Qt?
I would deploy the DLLs in the same directory as my app/plugin.
This does not answer your other concerns though.
正如 Tim 所说，您应该将 DLL 部署在与您正在制作的应用程序/插件相同的目录中。 我相信 PATH 变量不是您的程序查找 QT4 dll 的第一个位置，因此，如果您将其部署在同一文件夹中，您的应用程序将选择您的应用程序中的变量，并忽略 PATH 上的任何变量。
Q1：过去，似乎每个人都将 DLL 放在 system32 文件夹中，因为他们知道它位于 PATH 上，并且知道程序能够找到它。 从用户的角度来看，我发现当我想卸载某些东西时很难清理。 现在，由于存储成本较低，我想说将 DLL 与您的应用程序一起保留，特别是如果它们像这样可能有多个版本。 虽然我不是专家，但这就是我处理 Java 应用程序的 jar 文件的方式。
Q2：我也这么认为。 这取决于应用程序和插件的目录结构。 您可以告诉您的插件使用哪个版本，我愿意打赌该应用程序也已经在一个特殊的地方有它的版本。
Like Tim said you should deploy the DLL's in the same directory as the app/plugin you are making. I believe the PATH variable is not the first place your program will look for the QT4 dll so therefore if you deploy it in the same folder your app will pick up the one with your app and ignore any that are on the PATH.
Q1: In the past it seemed like everyone threw their DLLs in the system32 folder because they knew it was on the PATH and knew there program would be able to find it. From a user's point of view I find that very hard to clean up when I want to uninstall something. And now with the small price of storage I would say keep your DLLs with your app especially if they are like this where there could be multiple versions. While I'm no expert this is how I handle jar files for Java applications.
Q2: I would think so. It would depend on the directory structure of the app and plugin. You can tell your plugin which version to use and I'm willing to bet the app has its version in a special place already as well.
为了安全起见，您必须确保您的应用程序使用您希望其使用的 dll 版本。 Windows 保证首先查找应用程序文件夹。 所以你应该把所有的二进制依赖项放在那里。
如果您的应用程序在资源管理器中双击它时没有运行，Windows 会告诉您它需要什么 dll。 将该 dll 复制到应用程序文件夹。 如果您的应用程序正在运行，请转到下一步。
现在您应该暂时删除（或重命名）您放入应用程序文件夹中的 dll，并且每次您都应该双击您的应用程序。 如果 Windows 没有抱怨，它会在其他地方找到该 dll。 将该 dll 从 PATH 环境中取出（可能是暂时的）。 快速环境编辑器是一个免费实用程序，可编辑立即生效的环境变量。
仅当您确定您的应用程序使用应用程序目录中的 dll 并且没有从其他地方拉入任何 dll 时，您才可以再次开始编辑 PATH 变量以恢复旧情况。
For safety you must be sure that your application uses the dll versions you want it to use. Windows is guaranteed to look in the application folder first. So there you should put all your binary dependencies.
If your app does not run when you double click on it in explorer Windows will tell you what dll it needs. Copy that dll to the application folder. Go to the next step if your application runs.
Now you should temporarily remove (or rename) the dll's one by one that you have put in the application folder and each time you should double click your application. If Windows does not complain it found the dll somewhere else. Get that dll out of the PATH environment (possibly temporarily). Rapid Environment Editor is a free utility with edits environment variables which take effect immediately.
Only if you are sure your application uses the dll's in the application dir and does not pull in any dll from somewhere else you can start editing the PATH variable again to restore the old situation.