Я разрабатываю большой набор библиотечных библиотек C ++ для внешнего приложения (используя Visual Studio 2017 с набором инструментов 2015, если это имеет значение).Эти плагины, в свою очередь, содержат много кода, поэтому я поместил его в собственный общий файл dll с именем common.inc (я не могу использовать расширение .dll для него, иначе приложение хоста ошибочно принимает его за обычный плагин).Я бы предпочел поместить этот общий файл DLL рядом с другими библиотеками для удобства распространения.Common.inc должен быть извлечен через связывание во время загрузки, то есть не через ручные вызовы LoadLibrary / GetProcAddress (слишком много входов в common.inc для переноса).
Это должно сработатьof-the-box, если бы не тот факт, что хост-приложение не играет здесь честно.Кажется, что хост-приложение использует плоскую LoadLibrary против плагинов, которые оно находит, указывая полный путь к плагинам, и не пытается установить текущий каталог в папке плагинов, а также не использует LoadLibraryEx, чтобы указать дополнительный путь поиска или тому подобное.,В результате мои dll-плагины не могут связываться с common.inc прямо рядом с ними ...
Я бы не хотел загрязнять путь env var папкой плагинов хост-приложения илия хочу установить файл common.inc в папку установки хост-приложения или в папку Windows (дрожать).Мое решение до сих пор состоит в том, чтобы использовать файлы манифеста, чтобы направлять загрузчик Windows к common.inc при загрузке библиотек плагина, определяя частную сборку с файлом common.inc.
У меня это работает, но это не такхорошо (достаточно) как есть.В настоящее время я помещаю файл common.inc в папку «CommonFolder» рядом с плагинами, и помещаю в эту папку файл CommonFolder.manifest, перематывая файл common.inc внутри него.Я предполагаю, что это многофайловая сборка, но только с использованием одного файла.Я хотел бы превратить это в настоящую сборку из одного файла, чтобы избавиться от дополнительной папки + внешнего файла манифеста, но я не могу заставить его работать.
Что у меня есть,работает:
встроенный манифест plugin.dll (@ ID 2):
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<dependency>
<dependentAssembly>
<assemblyIdentity type="win32" name="CommonFolder" version="1.0.0.0"></assemblyIdentity>
</dependentAssembly>
</dependency>
<...trustinfo section left out...>
</assembly>
Содержимое CommonFolder:
- common.inc без встроенного манифеста
- CommonFolder.manifest
CommonFolder.manifest в свою очередь содержит:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<assemblyIdentity type="win32" name="CommonFolder" version="1.0.0.0" />
<file name="Common.inc" />
</assembly>
То, что я застрял, что не работает, это:
встроенный манифест plugin.dll (@ ID 2):
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<dependency>
<dependentAssembly>
<assemblyIdentity type="win32" name="Common.inc" version="1.0.0.0"></assemblyIdentity>
</dependentAssembly>
</dependency>
<...trustinfo section left out...>
</assembly>
common.inc рядом с plugin.dll со встроенным манифестом (@ ID 2):
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<assemblyIdentity type="win32" name="Common.inc" version="1.0.0.0"></assemblyIdentity>
<file name="Common.inc"></file>
<...trustinfo section left out...>
</assembly>
Я, наверное, тут много чего натворил, но мне пришлось пройти ускоренный курс о том, какие файлы манифеста были в первую очередь.Теперь, когда я чувствую себя более комфортно с манифестами, они на самом деле кажутся довольно простой концепцией, но все документы, которые я мог откорректировать в Google, кажется, не в состоянии передать это прямым способом (часто получая слишком много мета о них и, таким образом,актуальная тема, или только перечисление всех доступных низкоуровневых флагов и тегов XML без надлежащей привязки их к высокоуровневым концепциям)