Есть ли какие-либо недостатки в использовании LoadLibraryEx () вместо CoCreateInstance () для беспрерывного потребления COM-компонентов?

Question

Нашей программе необходимо использовать COM-сервер, который также сделан нами. Сценарий следующий: установщик будет копировать файлы программы и файлы COM-сервера в одну и ту же папку при каждой установке.

В настоящее время мы используем regsvr32 для регистрации COM-сервера, но это не очень хорошо - если мы разрабатываем другую несвязанную программу, которая также использует тот же COM-сервер (вероятно, другой версии), мы можем столкнуться с проблемами - так как CLSID неизменны сервер, зарегистрированный позже, будет использоваться обеими программами, и первая программа может работать неправильно.

Так что нам нужен рег-свободный COM. Мы могли бы использовать манифесты, но я поиграл с ними некоторое время и нашел их не очень удобными для использования в ночной сборке. Мы также могли бы переписать программу так, чтобы вместо вызова CoCreateInstance() она вызывала LoadLibraryEx(), затем GetProcAddress(), чтобы найти DllGetClassObject(), а затем просто извлекать фабрику классов и использовать ее.

Я сразу вижу некоторые недостатки:

• программа будет зависеть от точного имени файла COM-сервера
• Дополнительный код должен быть написан для вещей, обычно управляемых Windows
• COM-сервер должен быть внутрипроцессным, и сортировка никогда не будет использоваться

и эти недостатки, как правило, могут показывать заглушки, но совсем не выглядят плохо в нашем конкретном сценарии.

Есть ли другие недостатки в использовании LoadLibraryEx() / DllGetClassObject() по сравнению с CoCreateInstance()?

Answer 1

Я следую точной процедуре, которую вы описываете, чтобы реализовать мою собственную облегченную версию COM. Вы говорите о замене части «активации» COM. Я думаю, что вы перечислите все функции, которые предоставляет модель активации COM:

1. Вне процесса / поддержка в продвижении квартиры
2. Переадресация через реестр для определения местоположения библиотеки CoClass, допуская более новые версии, альтернативные реализации и т. Д.

Когда вы динамически загружаете библиотеку, извлекаете фабрику классов и создаете свой объект, она должна вести себя не иначе, как если бы вы создали внутри вашей квартиры объект в процессе работы через COM.

Answer 2

1 . программа будет зависеть на точное имя файла COM-сервера

Используя DLL-ловушки с задержкой загрузки уведомлений и обработкой dliNotePreLoadLibrary (то есть прерывая загрузку), вы можете загрузить из DLL, имя файла которой отличается от того, которое записано в таблице импорта клиента.

Фактически, вы можете указать фактическое имя файла DLL, которое вы хотите использовать в командной строке, или даже файл конфигурации. (Я только что сделал это недавно.) Пока вы не пытаетесь использовать библиотеку раньше времени.

2 . дополнительный код должен быть написан для вещи, обычно управляемые Windows

Что касается GetProcAddress, утилита с задержкой загрузки предоставляет функцию для загрузки всего импорта сразу из одного модуля.

3 . COM-сервер должен быть в процессе и сортировка никогда не будет использоваться

Что касается маршалинга - я не знаком с этой областью, но вот несколько идей:

• Нужно реализовать свой собственный код прокси / заглушки, обрабатывать межпроцессное взаимодействие по-своему

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

Как только это будет сделано, клиент будет LoadLibrary прокси, прокси-сервер запустит исполняемый файл заглушки (вне процесса) для размещения сервера, а заглушка LoadLibrary будет фактическим сервером.

По сути, это полное переосмысление COM.