在Visual Studio中构建的相互依赖的Dll [英] Mutually dependent Dlls built in Visual Studio

问题描述

我正在Visual Studio解决方案下构建9个32位Dll。

为了论证，每一个都依赖于所有其他人。换句话说，每一个都从其他8中导入符号并导出由其他每个导入的符号8.



目前我通过2个构建配置来执行此操作。第一个尝试编译和链接所有dll。

所有编译都成功但当然所有链接都失败了。然而，构建为每个DLL输出.exp文件和.lib文件



然后运行第二个配置，再次编译所有内容然后忽略它刚制作的大多数文件并链接libs和导出文件从第一个配置构建实际的Dll。



这是有效的，但它是一个可怕的黑客，需要两倍的时间。



我需要的是一种让Visual Studio为我排序或停止第一次配置试图链接而第二种配置形式浪费时间的方法再次编译所有内容。



大约一年前我在VS论坛上问了一个类似的问题，并被告知这可以通过使用项目依赖项设置来解决。它不能，因为你不能创建循环依赖。



我正在做的与描述此处 [ ^ ]但是使用Visual Studio。

I am building 9 32bit Dlls under a Visual Studio solution.
For the sake of argument each one of them is dependent on all the others. In other words each one imports symbols from the other 8 and exports symbols imported by each of the other 8.

At the moment I do this by having 2 build configurations. The first tries to compile and link all the dlls.
All the compilations succeed but of course all the linking fails. The build however outputs .exp files and .lib files for each DLL

The second configuration is then run which compiles everything again and then ignores most of the files it's just made and links the libs and export files from the first configuration to build the actually Dlls.

This works but it is a horrible hack and takes twice as long as necessary.

What I need is a way to either get Visual Studio to sort this out for me or to stop the first configuration from trying to link and the second configuration form wasting its time compiling everything again.

I asked a similar question in the VS forum about a year ago and was told that this could be fixed by using the project dependency settings. It can't, as you can't create circular dependencies.

What I'm doing is the same as described here[^] but with Visual Studio.

推荐答案

你所使用的绝对是反模式。允许DLL之间的循环依赖是一个坏主意，不仅在DLL的情况下，而且在静态库的情况下。如果2个DLL相互引用，那么它们会在1 btw上保持彼此引用计数，这不是世界末日，因为你最终可能会以ExitProcess结束生命。

更改你的项目方式：你有lib1和lib2。让lib1依赖于lib2。要从lib2回复到lib1，请执行以下操作：在源代码中定义一个对两个库都可见的接口。在lib1中创建此接口的实现。当lib 1与lib2进行通信时，例如通过调用lib2 :: Init（），你将一个接口指针传递给lib2，这样lib2就可以调用lib1中的代码。

What you are using is definitely an antipattern. Allowing cyclic dependency between DLLs is a bad idea not only in case of DLLs but also in case of static libs. If 2 DLLs reference each other then they keep each others reference count on 1 btw, that isn't the end of the world because you probably end their life with ExitProcess at the end.
Change your project this way: You have lib1 and lib2. Let only lib1 to depend on lib2. To communicate back from lib2 to lib1 do the following: Define an interface in your source code that is visible to both libs. In lib1 create an implementation of this interface. When lib 1 communicates to lib2 for example by calling lib2::Init() you pass an interface pointer to lib2 so lib2 will be able to call code inside lib1.

我做过这种类型之前的事情。这有点痛，但可以做到。我将描述2个DLL之间的链接，我认为你可以概括。设置链接，以便A.dll编译并正确链接到B.dll。在B.dll中，使用指向A.dll API的函数指针，当需要从B.dll调用A.dll时，为每个API调用创建存根代码，在A.dll上执行LoadLibrary并查找API使用GetProcAddress（）。这种簿记只需要完成一次，可以缓存在静态表中。在A.dll中使用externC链接不是强制性的，但会简化名称查找混乱。

I have done this type of thing before. It is a bit of a pain but it can be done. I will describe the linkage between 2 DLLs, which I think you can generalize. Set up the linkage so that A.dll compiles and links properly to B.dll. In B.dll, use function pointers to the A.dll APIs, and when you need to call A.dll from B.dll, have stub code for each API call do a LoadLibrary on A.dll and lookup the API(s) with GetProcAddress(). This bookkeeping only needs to be done once and can be cached in a static table. Use of extern "C" linkage in A.dll is not mandatory but will simplify the name lookup mess.

这篇关于在Visual Studio中构建的相互依赖的Dll的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！