Программный выбор dll с com-классами

← →
hellmachine (2003-11-27 11:50) [0]

Добрый день, мастера! Есть несколько библиотек, с одним com-классом в каждой; каждый com-класс реализует один и тот же интерфейс (имя, guid задан). Вопрос: возможно ли в run-time выбирать библиотеку и создавать экземпляр com-класса, описанного в ней? И что кроме пути к библиотеке нужно обязательно знать о создаваемом ком-классе?

← →
me (2003-11-27 13:56) [1]

Это противоречит концепции СОМ - каждый СОМ-сервер должен реализовать СВОЙ интерфейс и регистрировать его в системном реестре (так что на один guid не "повесить" хотя бы два сервера). И как раз о пути к серверу клиент ничего не знает - СОМ-среда все ещет и грузит сама, глядя в рестр.

← →
hellmachine (2003-11-27 14:47) [2]

ты не понял; guid задан для абстрактного интерфейса, который реализует каждый из набора классов; разумеется, у каждого класса в наборе будет свой guid - связывать их будет только то, что они реализуют(implements) общий интерфейс;

задача - каким-то образом определить доступные(зарегистрированные) классы и выбрать один из них;

← →
Nikolay M. © (2003-11-27 15:25) [3]

Это случайно не похоже на сосуществование нескольких версий офиса?
Excel.Application.8, Excel.Application.9 и проч., а Excel.Application - по умолчанию последняя версия?

← →
hellmachine (2003-11-27 16:40) [4]

нет; попытаюсь объяснить еще раз:
Допустим, есть простое приложение, которое должно вычислять какую-то функцию. Предположим мы хотим обобщить это приложение таким образом, чтобы оно вычисляло несколько разных функций, причем таким образом, что на этапе компиляции приложения мы не будем знать, какие это будут функции. Тогда делаем следующим образом: договариваемся какие аргументы будет принимать функция и какие возвращать, помещаем функцию в динамическую библиотеку, кладем библиотеку в оговоренный каталог. Приложение на запуске просматривает оговоренный каталог, выбирает все dll и вызывает функцию из них, использую «явный вызов».
В моем случае, надо организовать что-то подобное, только вместо функции будет класс. Поэтому я выбрал технологию com. Создал общий класс с интерфейсом, затем несколько разных классов, которые реализуют интерфейс общего класса (в других библиотеках). Теперь стоит следующая проблема: что надо оговорить, чтобы находить библиотеки с классами, реализующие этот интерфейс и создавать представители классов, описанных в них.

← →
dimmu (2003-11-27 16:43) [5]

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

← →
me (2003-11-27 17:11) [6]

Если имеется возможность разрабатывать все это в рамках СОМ, то можно использовать COM Components Categories - подробности в MSDN

← →
Бином Ньютоныч (2003-11-27 17:14) [7]

Интерфейс у них один, но clsid - то разный. А его-то и надо указывать в CoCreateInstance. Али чего?
Но можно и конкретную реализацию если есть несколько либ с классами с одинаковыми clsid: LoadLibrary + DllGetClassObject..

← →
hellmachine (2003-11-27 18:26) [8]

Да действительно; Я вроде начал постепенно разбираться как это должно работать;

Я подключил _TLB от общего класса, и программно подменяю ClassId в CreateComObject();

Осталось решить проблему как искать библиотеки, реализующие заданный интерфейс. Можно конечно самому в реестре ClassId посмотреть и записать их в .ini, но уж больно неэлегантно :)

Посоветуете что-нибудь по поиску?

← →
Бином Ньютоныч (2003-11-27 18:46) [9]

А вот тут как раз Components Categories будут к месту, по категории и будешь считывать. Хотя можешь и в свою ветку реестра заодно записывать классы при регистрации, смотри ClassFactory.Updateregistry. Но я бы сделал стандартно, через Components Categories, в системе все уже есть.

← →
Саша (2003-11-28 21:11) [10]

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

Программный выбор dll с com-классами Найти похожие ветки