Связь между двумя DLL внутри одного процесса

Question

У меня есть приложение, которое загружает "aaa.dll". «aaa.dll» загружает две другие библиотеки «bbb.dll» и «ccc.dll».

aaa.dll - это сторонняя dll, написанная не мной. Но bbb.dll и ccc.dll написаны мной.

Есть ли способ для bbb.dll и ccc.dll общаться друг с другом? Указание на любой ресурс будет очень полезным.

Тип связи: мне нужно отправить состояние как установлено или нет из bbb.dll в ccc.dll.

Спасибо всем. LoadLibrary () / GetProcAddress сделали свое дело. Я хотел убедиться, что bbb.dll не загружает вторую копию ccc.dll. Кроме того, межпроцессное взаимодействие кажется излишним, поскольку мне нужно было внутрипроцессное взаимодействие.

Спасибо всем еще раз.

Answer 1

DLL не общаются. Занятия общаются. Подумайте о классах, в которых нужно общаться друг с другом, и ответ будет гораздо более понятным.

Answer 2

Вы можете использовать любой из широкого спектра Win32 IPC - общую память, мьютексы, события и т. Д., Чтобы получить более подробную информацию о том, какой тип связи вам необходим, а форум даст вам более конкретные советы.

Answer 3

Вы можете делать прямые вызовы API. Он находится в том же процессе, поэтому статические объекты также будут общими.

Answer 4

Вам нужна третья сборка, чтобы действовать как интерфейс между ними. Эта сборка интерфейса будет экспортировать все необходимые объекты и / или методы, необходимые для взаимодействия двух других сборок.

Этот следующий пример, конечно, рассматривает .NET как платформу, но ту же самую точную концепцию можно использовать в проектах Win32 / C ++.

Это довольно сложно с точки зрения архитектуры. Две библиотеки DLL в .NET не могут напрямую взаимодействовать двумя способами без каких-либо накладных расходов, однако вы можете общаться одним способом. Причина в том, что вы можете ссылаться только на одну сборку из другой, в противном случае у вас будет циклическая ссылка.

Хотя есть простое решение, но для этого потребуются три сборки с вашей стороны. Возьмите следующие сборки:

• Interface.dll
• client.dll
• Server.dll

Только по именам вы сможете понять, как это будет работать. По сути, Interface.dll будет содержать открытые объекты, которые Client.dll и Server.dll должны будут взаимодействовать друг с другом. И Client.dll, и Server.dll будут ссылаться и Interface.dll для получения доступа к этим объектам.

При использовании этого метода обе сборки имеют доступ ко всем объектам, с которыми любой из них должен был бы общаться. Interface.dll также будет содержать открытые методы, которые должны взаимодействовать как Client.dll, так и Server.dll. Таким образом, он может содержать, например, методы «Отправить» и «Получить», которые могут использовать либо Client.dll, либо Server.dll.

Для этого вам придется разработать какой-то стандарт связи.

• Что эти сборки будут связываться друг с другом?
• Как эти сборки будут взаимодействовать?

С учетом этих двух факторов, независимо от того, передаете ли вы реальные классы и объекты или просто сообщения, третья сборка, которая справится с этим, будет работать безупречно, если приложить усилия к архитектуре и дизайну.

Не принимайте имена близко к сердцу, Client.dll, Server.dll и Interface.dll - это всего лишь примеры общей методологии выполнения такой задачи. При использовании этого метода не было бы циклических ссылок, и поэтому ваши сборки могли взаимодействовать двумя способами, а не одним.

Answer 5

ccc.dll должен экспортировать функцию SetState. Затем bbb.dll может вызывать указанную функцию всякий раз, когда это необходимо. Вам нужно будет связать bbb.dll с ccc.dll, статически или через LoadLibrary / GetProcAddress.