Регистрация сервера автоматизации в системе.

← →
bkv (2002-12-26 10:32) [0]

Зарегистрировать ActiveX сервер я могу из Дельфи во время разработки.
А как зарегистрировать его на другой машине?
И еще. Как зарегистрировать библиотеки типов?
Заранее благодарен.

← →
Lady D (2002-12-26 11:42) [1]

%windir%\system32\regsvr32.exe c:\MyProg\MyComDll.dll - WinNT
%windir%\system\regsvr32.exe c:\MyProg\MyComDll.dll - Win9x

← →
bkv (2002-12-26 13:05) [2]

А если сервер автоматизации внутренний,
можно его зарегтстрировать вызовом его стандартной функции-
DllRegisterServer?

← →
Lady D (2002-12-26 13:13) [3]

regsvr32.exe вызывает этот метод. А вот чтобы из самого себя его вызвать, я сильно сомневаюсь. Да и HELP нам говорит что:

Do not call DllRegisterServer directly. DllRegisterServer is exported by in-process ActiveX servers (DLLs) and instructs the DLL to create its registry entries for the type library and all classes supported in that server module. DLLRegisterServer is usually called when the ActiveX server is installed on a user"s system.

← →
asmith (2002-12-26 13:42) [4]

Библиотеку типов regsvr32 регистрировать не умеет, зато это умеет делать борландовый tregsvr (имеются сорсы!).

← →
bkv (2002-12-26 13:48) [5]

А если я обращаюсь к серверу автоматизации с удалленных клиентских
машин, то на клиентских машинах тоже надо регистрировать этот сервер автоматизации?

← →
Fantasist (2002-12-27 08:42) [6]

> Библиотеку типов regsvr32 регистрировать не умеет

Хм, а он разве должен? В своей реализации я прописываю регистрацию библиотеки типов внутри DllRegisterServer. Считается, что она включена как ресурс.

← →
Mute (2002-12-27 11:41) [7]

Посмотри раздел HELPа "COM utilities".

RegisterComServer - registers an in-process COM server with the operating system.
CreateRemoteComObject - creates a Com object on another machine and returns an IUnknown interface for it.
А если работа идет удаленно, то IMHO нужно использовать DCOM.

← →
asmith (2002-12-27 14:11) [8]

>bkv (26.12.02 13:48)
Обязательно! Именно регистрация сервера на клиентах регистрирует на них серверную библиотеку типов, иначе при запуске "Interface not supported". Для регистрации сервера на клиенте просто нужно его запустить и все.

← →
kig (2002-12-27 16:19) [9]

А на кой сервер нужен на удаленном клиенте???

Достаточно typelib.

А можно и без нее, если поздним связыванием работать, что впрочем не желательно.

← →
asmith (2002-12-27 17:44) [10]

Конечно, если пишется инсталлятор (например, на InstallShield), можно при установке клиента зарегестрить typelib. А если по-простому - то просто запустить сервер на клиентской стороне, а потом стереть, если мешает. Борланд сама советует так делать (см. справку, раздел Developing COM-based applications, параграф Registering a COM object. Результат в обеих случаях будет одинаков - регистрация библиотеки типов.

← →
Mirolex (2002-12-27 17:48) [11]

Если я правильно понял о чем речь, то посмотри родные Demo, кот. показывают как делать сервера автоматизации. Сервер автоматизации можно зарегестрировать (не ручаюсь за точность, давно с этим работал) просто передав параметры. для регистрации:
MyProgramServer.exe /regserver и для отмены: MyProgramServer.exe /unregserver.

← →
Fantasist (2002-12-27 21:39) [12]

> Достаточно typelib.
>
> А можно и без нее, если поздним связыванием работать, что
> впрочем не желательно.

Стоп! Я всю свою недолгую жизнь думал, что первым делом клиенту (удаленному, в данном случае) нужна proxy. TypeLib подойдет, если исползуются только типы совмещенные с автоматизацией, тогда стандартный маршалер справиться. Но позднее связывание? Проксю нужно создать. Положим, действительно, для IUnknown/IDispatch можно использовать некий стандартный маршалер - эти интерфейсы стандартизированны. Но как можно гарантировать, что клиент не получит через QueryInterface какой-либо другой интерфейс? Стоит ему так сделать, как все грохнеться без видимых причин. Что этот стандартный маршалер теперь должен выборочно пропускать вызовы QueryInterface?

← →
kig (2002-12-27 22:16) [13]

2 Fantasist © (27.12.02 21:39)

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

Согласен. Если не automation типы, тогда ручками маршалить придется.

Но позднее связывание? Проксю нужно создать. Положим, действительно, для IUnknown/IDispatch можно использовать некий стандартный маршалер - эти интерфейсы стандартизированны. Но как можно гарантировать, что клиент не получит через QueryInterface какой-либо другой интерфейс?

А что, при позднем связывании при вызове сервера используется что-то кроме IUnknown/IDispatch?

А как по QueryInterface запросить любой интерфейс, не имея typelib? GUID любого интерфейса где взять?

← →
Fantasist (2002-12-28 20:39) [14]

> Согласен. Если не automation типы, тогда ручками маршалить
> придется.

Ну необязвательно ручками: midl сгенерирует тебе proxy/stub.

> А как по QueryInterface запросить любой интерфейс, не имея
> typelib? GUID любого интерфейса где взять?

Да по телефону спросить! Какая разница? Теоретически это вполне возможно. Например, я сам написал и сервера и клиента, и есть у меня заголовочный файл с интерфейсами и с GUID"ами, который я, естессвенно, использовал и в клиенте. Вполне нормальная ситуация. Клиент знает о всех интерфейсах и гуидах, а система нет - Typelib я забыл зарегестрировать.

← →
asmith (2002-12-29 14:43) [15]

Давайте рассуждать конкретнее. Для обеспечения маршалинга между клиентом и сервером имеются такие варианты:
1.Описать интерфейс на языке IDL и компилятором MIDL от MS сгенерировать proxy-stub-DLL.
2.Сделать сервер совместимым с OLE Automation. В этом случае COM сам создаст proxy, используя описание сервера из его библиотеки типов. "Even if the object does not implement IDispatch, if it limits itself to automation-compatible types and has a registered type library, COM automatically provides marshaling support." - написано в справке по Делфи. Т.е. для использования стандартного маршалинга достаточно ограничиться OLE-совместимыми типами данных и зарегистрировать Typelib-у.
3.Реализовать на сервере интерфейс IMarshal и, при необходимости, — proxy-DLL, которая будет загружена на клиенте для реализации proxy.
Далее. Если мы пишем сервер и клиента на Дельфи, то вариант 1 нам недоступен вовсе, а последний весьма труден. Так что остается второй - использование стандартного маршалинга.

← →
Fantasist (2002-12-30 21:27) [16]

> Давайте рассуждать конкретнее

Гхм.. Не понял. Все эти варинты, безусловно, имеют место, и все они нами уже были упомянуты, однако их строгое перечисление не дает никакого ответа на тот вопрос, что был обсуждаем. Человек утверждал, что возможно создавать удаленный COM на сервере, НЕ регистрируя библиотеку типу на клиенте,если ограничется только общеним через IDispatch. Второй раз я слышу это утверждение (первый раз его связали с СОМ+) - хотелось бы разобраться что к чему.

← →
asmith (2002-12-30 22:03) [17]

> Человек утверждал, что возможно создавать удаленный COM на сервере, НЕ регистрируя библиотеку типу на клиенте,если ограничется только общеним через IDispatch
Это не есть справедливо. Породив свой интерфейс от IDispatch, мы только лишь даем возможность использовать стандартный маршалинг. И все. Без регистрации на удаленной машине СОМ просто не найдет AppID сервера, чтобы запустить его, не говоря уже о CLSID-ах. И никакой IDispatch не поможет.

← →
Набережных С. (2002-12-31 11:28) [18]

>Fantasist © (30.12.02 21:27)

Никогда не задавался этим вопросом,т.к. не вижу особого смысла, но, вероятно, так и есть. Библиотека типов на клиенте нужна для работы универсального маршалера PSOAInterface, обслуживающего OLE-совместимые VTbl-интерфейсы. А для IDispatch имеется маршалер стандартного типа PSDispatch, вряд ли ему требуется дополнительная информация. Разумеется, если попытаться через IDispatch получить другой интерфейс(кроме IUnknown), то получим "интерфейс не поддерживается" из-за отсутствия библиотеки типов.

>asmith (30.12.02 22:03)

Регистрация сервера и регистрация его библиотеки типов - это, все-таки, не одно и тоже.

← →
Fantasist (2002-12-31 20:43) [19]

> А для IDispatch имеется маршалер стандартного типа PSDispatch,
> вряд ли ему требуется дополнительная информация.

Так в том-то и дело. Чтобы маршалить IDispatch никакой дополнительной информации и ненужно, но нужна информация о том, что никакой интерфейс кроме IDispatch (ну и IUnknown) использоваться не предполагается. Теоретически тут можно сделать и так и так, но давайте смотреть практически. Вот я система. Меня просят создать удаленный объект (вызовом CoCreateInstance) и вернуть IDispatch. Я лезу в реестр, и обнаруживаю, что ни библиотеки типов, ни прокси/стаб не зарегестрированны на локальной машине. Что я должен делать?
Вариант один: обломать все это дело с соответсвующей ошибкой.
Вариант два: просто создать прокси для IDispatch/IUnknown, и оставить все как есть. В этом случае, если пользователь вызовет QueryInterface и получит другой интерфейс, то он долго будет гадать почему все грохается без видимых причин. Этот вариант не подходит.
Вариант три: создать прокси для IDispatch/IUnknown с заглушками на вызовы QueryInterface, которые, прежде чем передать вызов, будут проверять какой интерфейс спрашивается, и если это не IDispatch/IUnknown возвращать E_NOINTERFACE. Тогда пользователь тоже может долго гадать, почему так происходит - он ведь знает, что интерфейс существует.

Первый вариант самый очевидный и ясный. Второй возможно мною не совсем правильно обрисован, так как знаний не хватает - может быть это то же самое, что третий. Я предполагаю, что прокси на клиенте и стаб на сервере создаются системой локально и без взаимной верификации, то есть на сервере стаб будет полнофункциональным маршалером, созданным по информации на сервере, тогда как прокси нет. Третий - это то что возможно, в свете того, что я слышал, однако тоже хромой, на мой взгляд.
Вообще, оптимальнее всего, было вставить соответсвующую функциональность в ОС, дабы можно было явно указывать, что я буду использовать только IDispatch, тогда системе понятно что делать, и мне понятно, почему она так делает.
Теоретически тут все понятно, но как происходит практически?
Правильно, для этого надо, заканчивать с теоретизированием и идти читать MSDN. Хотя там тоже не на все есть ответ.

← →
Fantasist (2002-12-31 20:55) [20]

Кстати, уже в 2000 году, в MSDN была опубликована статья "Is COM Dead?" в которой автор обрисовывал многие недостатки COM, противопоставляя им соответвующие решения в .NET. Он утверждает, что COM - пройденный этап, и все мы заживем счастливо без него, как только .NET станет достадочно распространена.

← →
Набережных С. (2002-12-31 23:22) [21]

>Fantasist © (31.12.02 20:43)

Попробую по порядку, в меру трезвости:)

>Я лезу в реестр, и обнаруживаю, что ни библиотеки типов, ни прокси/стаб не зарегестрированны на локальной машине. Что я должен делать?

Прокси/стаб для IDispatch всегда имеется. Посмотри в реестре ключ
HKEY_CLASSES_ROOT\Interface\{00020400-0000-0000-C000-000000000046}
Это и есть IDispatch. Там есть подключ \ProxyStubClsid32 - это маршалер. Он находится в файле oleaut32.dll и всегда есть в системе. При создании объекта SCM первым делом запрашивает у него IMarshal. Если ответ положительный, то маршалинг - дело самого объекта. В противном случае для всех запрашиваемых интерфейсов действует следующий механизм:
Ищется подключ ProxyStubClsid32. Если его нет - INTERFACE_NOT_SUPPORTED. Если там CLSID универсального маршалера, то проверяется наличие( там же, у интерфейса) подключа TypeLib.Если его нет - та же ошибка, иначе создается Proxy/Stub и ему передается библиотека. Наконец, если там иной CLSID, то это - обычный маршалер стандартного типа, которому не нужна никакая дополнительная инфа, ну и далее - обычная последовательность действий, если интересно - посмотри в MSDN, подробно расписано. Заметь, вся работа при создании Proxy/Stub идет с регистрационной информацией интерфейса, а не конкретного объекта.
Разумеется, PSDispatch, не может и не должен строить предположения о каких-то твоих дальнейших действиях. Если ты решил не регистрировать библиотеку типов на клиенте, то это - твоя ответственность как программиста. Конечно, ничего не "грохнется без видимых причин", а просто вернет уже упомянутую мною ошибку и все станет ясно:) Но, как я уже упоминал, я не вижу никакого смысла не регистрировать библиотеку типов на клиенте.

>Правильно, для этого надо, заканчивать с теоретизированием и идти читать MSDN.

А вот это - стопудово! :)))

>Хотя там тоже не на все есть ответ.

Там есть практически вся необходимая информация, прямо или косвенно. А отальное можно додумать:)

>Fantasist © (31.12.02 20:55)

Поживем - увидим. У COM немало недостатков, в том числе и пресловутый "ад DLL", но и достоинств много. Как правило, новая технология решает некоторые проблемы старых, а взамен создает свои. Посмотрим, что перевесит:)

С НОВЫМ ГОДОМ!

← →
Fantasist (2003-01-02 03:36) [22]

> Набережных С.

О! Спасибо, это было круто! Незнаю, какая у вас была мера трезвости, но описанно очень доходчиво. :)

> Но, как я уже упоминал, я не вижу никакого смысла не регистрировать
> библиотеку типов на клиенте.

Большого смысла нет, но мало ли... Типа недоступна она.

> С НОВЫМ ГОДОМ!

Присоед...

Регистрация сервера автоматизации в системе. Найти похожие ветки