创建链接到另一个 dll 的 dll (MSVS2008 C++)
我目前正在用 C++ (MSVS 2008) 创建我自己的框架，它导出一个带有一堆函数的 dll，供我的框架的用户使用/调用。一开始，当我的项目还很小时，一切都运行良好。我编译了我的项目。吐出一个MyFramework.dll和MyFramework.lib。我假装是一个用户；将 MyFramework.dll 文件放入我的新 VS 项目的 Debug 文件夹中，将 MyFramework.lib 和 MyFramework.h 文件放入我的项目文件夹中，在我的代码中 #include-d MyFramework.h ，瞧，我可以调用（仍然简单）我的新项目中的框架功能。
但现在我已经扩展了我的框架。它现在使用自己的外部 dll（让我称之为 Graphics.dll）并以相同的方式包含它（.dll 在 Debug 文件夹中，.lib/.h 在项目文件夹中，#include Graphics.h 在代码中）。
问题是，当我现在创建 MyFramework.dll/MyFramework.lib 并将其包含在我的新项目和构建中时，链接器抱怨无法包含 Graphics.h，它显然包含在 MyFramework.dll 中的某处。
所以我的问题。我希望 MyFramework.dll 的用户只需在其项目中包含 MyFramework.* 文件，而无需复制/粘贴我决定在 MyFramework 中使用的所有外部库。我怎样才能做到这一点？我查看了这个线程。它说的是关于添加现有项目并按“添加”按钮旁边的小箭头，但是...该箭头在我的 MSVS 版本中不存在...
非常感谢帮助。
亲切的问候 W·斯佩克
I am currently creating my own framework in C++ (MSVS 2008) which exports a dll with a bunch of functions for a user of my framework to use/call. In the beginning, when my project was still small, all worked fine. I compiled my project. A MyFramework.dll and MyFramework.lib were spit out. I pretended to be a user; put the MyFramework.dll file in my new VS project's Debug folder, put the MyFramework.lib and MyFramework.h file in my project folder, #include-d MyFramework.h in my code and voilá, I could call the (still simple) framework functions from within my new project.
But now I have expanded my framework. It now uses an external dll of its own (let me call it Graphics.dll) and included it in the same way (.dll in Debug folder, .lib/.h in project folder, #include Graphics.h in code).
The problem is that when I nów create MyFramework.dll/MyFramework.lib, include it in my new project and build, the linker complains about not being able to include Graphics.h, which obviously was included in MyFramework.dll somewhere.
So my question. I would like the user of MyFramework.dll to solely have to include the MyFramework.* files in their project and not have the need to copy/paste all external libraries I decide to use in MyFramework. How can I accomplish this? I took a look at this thread. It says something about adding an existing item and pressing the small arrow next to the "Add" button, but...the arrow is nonexistent in my version of MSVS...
Help is very much appreciated.
Kind regards
W. Spek
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
发生的情况是用户包含了您的库的头文件之一。该文件然后包含“graphics.h”。如果您不想要求用户有权访问此文件，则必须在库界面中隐藏它。
也就是说你的库必须有公共api头文件和私有实现头文件。您的用户仅包含公共 api 头文件，不包含任何第三方或私有包含文件。当这些文件引用私有类型或第三方类型时，它们只能使用指针或引用，这些是前向声明的。这使得类的私有部分能够使用私有库代码和第 3 方类型。
使用 Pimpl Idiom 很可能会为您解决此问题。
What is happening is the user is including one of your library's header files. This file is then including "graphics.h". If you don't want to require your users to have access to this file you must hide it from your libraries interface.
That is your library must have public api header files and private implementation header files. Your user only includes the public api header files, these do not include any 3rd party or private include files. When these files reference private types or 3rd party types, they can only use pointers or references, these are forward declared. This enables the private part of a class to use private library code and 3rd party types.
The chances are using the Pimpl Idiom will fix this for you.
“问题是，当我现在创建 MyFramework.dll/MyFramework.lib，将其包含在我的新项目和构建中时，链接器抱怨无法包含 Graphics.h，它显然包含在 MyFramework.dll 中的某处。”
你把头文件的路径放了吗？编译器报告头文件与正在转换的 cpp 文件不在同一目录中，并且也没有在附加包含目录中列出。
转到“项目”->“属性”，然后选择“C/C++”，
您将看到的第一个选项是“其他包含目录”。您需要将标头 Graphics.h 的路径与所有其他需要用分号分隔的路径一起放入其中。我在 mo 打开的项目有，例如：“../AudioLibrary;../CoreLibrary;”
编辑：从您对 Mark 帖子的评论中，您说您希望将 Graphics.DLL 嵌入到您的 DLL 中。我的回答如下：
如果您没有 Graphics.dll 的源代码，那么您就有问题了。你所要求的是可能的，但做起来非常复杂。基本上你不能使用LoadLibrary。您将被迫编写自己的 LoadLibaray 和 GetProcAddress 来查看嵌入的 DLL，而不是尝试在磁盘上找到它......它是可行的，但您将需要在 可移植可执行 (PE) 文件结构。
"The problem is that when I nów create MyFramework.dll/MyFramework.lib, include it in my new project and build, the linker complains about not being able to include Graphics.h, which obviously was included in MyFramework.dll somewhere."
Have you put the path to the header file? The compiler is reporting that the header file is not in the same directory as the cpp file being converted and its not listed in the additional include directories either.
Go to Project->Properties then select C/C++
The first option you'll see is "Additional Include Directories". You need to put the path to your header Graphics.h in there along with any other paths required all semi-colon seperated. The project I have open at the mo has, for example: "../AudioLibrary;../CoreLibrary;"
Edit: From your comments to Mark's post you say you want to embed the Graphics.DLL in your DLL. My answer is as follows:
If you don't have the source code to the Graphics.dll then you have a problem. What you are asking IS possible but VERY complex to do. Basically you can't use LoadLibrary. You will be forced to write your own for of LoadLibaray and GetProcAddress that will look at the embedded DLL and not try and find it on disk ... Its doable but you are going to need to do a lot of reading on the Portable Executable (PE) file structure.
如果您不想要求用户拥有或包含 Graphics.h，一种解决方法是使用
LoadLibrary在运行时动态加载Graphics.dll。这意味着用户将能够在 Graphics.dll 不可用的情况下针对 MyFramework 进行编译，因此如果 LoadLibrary 失败，最好进行某种错误报告。
在 Graphics.dll 上成功调用
LoadLibrary后，您需要使用GetProcAddress——这实际上会给你函数指针。如何存储函数指针取决于您；我通常更喜欢在导入的函数周围包装一个类，但没有什么可以阻止您将函数指针保留在全局范围内。As mentioned in the comments, if you don't want to distribute Graphics.dll at all, it will need to be a static library (i.e. "built in" to MyFramework.dll). If you do want to distribute Graphics.dll (so the user can use Graphics.dll without MyFramework.dll), then the above approach remains the better option. Really, the above approach assumes you are distributing Graphics.dll with MyFramework.dll, but that the user may not necessarily have Graphics.h available.
If you don't want to require the user to have or include Graphics.h, one way around that is to use
LoadLibraryto dynamically load Graphics.dll at runtime.This will mean that the user will be able to compile against MyFramework without Graphics.dll being available, so it might be wise to do some kind of error reporting if LoadLibrary fails.
Once you have successfully called
LoadLibraryon Graphics.dll, you'll need to manually import each function (and its signature) usingGetProcAddress-- this will actually give you function pointers. How you store the function pointers is up to you; I generally prefer to have wrap a class around the imported functions but there's nothing stopping you from keeping the function pointers in the global scope.As mentioned in the comments, if you don't want to distribute Graphics.dll at all, it will need to be a static library (i.e. "built in" to MyFramework.dll). If you do want to distribute Graphics.dll (so the user can use Graphics.dll without MyFramework.dll), then the above approach remains the better option. Really, the above approach assumes you are distributing Graphics.dll with MyFramework.dll, but that the user may not necessarily have Graphics.h available.