Текущий архив: 2004.10.24;
Скачать: CL | DM;
Внизрегистрация сервера приложения DCOM на клиенте Найти похожие ветки
← →
kostik78ua (2002-07-29 11:41) [0]Помогите новичку!
Создал сервер приложения svr1.dll (а также клиента). На одной машине сервер и клиент коннектятся нормально, но только развел на разные машины, пишет "Сервер не зарегистрирован".
Прочитал, что на всех клиентских местах надо зарегистрировать.
Что-то типа: regsvr32 svr1.dll Но ведь на клиентской машине этой dll-ки НЕТ. Как прописать эту строку?
← →
А. Н. Оним (2002-07-29 12:10) [1]Сервер в DLL в случае одной машины для клиента и сервера грузится в адрессное пространство клиентского процесса в момент создания экземпляра CoClass"а. Поэтому на одной машине у тебя всё и работало.
В случае разных машин, транспортировка DLL-сервера по сети не предполагается на машину клиента с последующей загрузкой в его адрессное пространство. Но в то же самое время, DLL должна получить своё "место жительства" в чьём то адрессном пространстве для своей работы. В DCOM это реализовано следующим образом. На сервере по запросу должен подняться хостящий процесс, который загрузит твою DLL к себе и уже с ним ты и будешь общаться. Такой хостинг выполняет утилита dllhost.exe;
Для того, чтобы настроить твою DLL для хостинга каким-то приложением при запросе с другой машины, необходимо прописать в реестре под AppID ключ DllSurrogate с именем хостящего процесса [dllhost.exe](кажется так, точно не помню, уточни где-нибудь).
Но даже так мало кто делает потому, что DLL имеет выгоды по скорости вызова методов только в InProc взаимодействии, что возможно только на одной машине. В случае нескольких станций работа с ней уподобляется работе с сервером в EXE, в качестве которого и будет выступать DllHost. Поэтому пиши сразу сервер в EXE.
Но даже здесь проблемы не закончатся, а только начнутся. Предстоит настроить политику безопасности серверной машины. Наиболее удобно это сделать при помощи утитилиты dcomcnfg.exe
Твой сервер должен давать клиенту права на доступ (и возможно) запуск. Хорошо, если у тебя в сети стоит контроллер домена - тогда пользователя клиентской машины можно будет создать в домене и на сервере дать ему права, но если контроллера нет, тогда пользователь клиента (его учётная запись) должен быть продублирован вместе со своим паролем на сервере.
← →
А. Н. Оним (2) (2002-07-29 12:26) [2]
DLL действительно должна быть зарегистрирована как на клиентской, так и серверных машинах. Клиенту она сама по себе не нужна (так как не к ней он будет обращаться), но важна регистрация интерфейсов коклассов этой DLL в реестре клиента (может быть, зарегистрировав её раз, можно потом и удалить с диска).
Дело в том, что SCM на клиентской машине будет загружать в адрессное пространство клиента прокси кокласса сервера, к которому клиент обращается. Откуда взять Proxy - SCM решает на основе зарегистрированных интерфейсов. Каждый интерфейс (из HKEY_CLASSES_ROOT\Interfaces) может содержать вкладку ProxyStubClsid32 - указывающий на Clsid своего прокси. Если твой интерфейс подходит под определение OleAutomation, то пойдёт стандартный Proxy (его CLSID {00020424-0000-0000-C000-000000000046} - самый самый распространённый среди Proxy CLSID"ов), а если нет, то придётся строить свою Proxy/Stub Dll и регистрировать её как на клиенте, так и на сервере. Можешь поэкспериментировать, какой сюрприз вылезает, если на клиенте нет ProxyStub DLL, но на сервере есть (IUnknown ты получишь, но только его).
← →
Pitek (2003-04-21 16:54) [3]DLL - это СОМ или СОМ+
Может лучше дейстивельно DCOM написать? ;-)
Страницы: 1 вся ветка
Текущий архив: 2004.10.24;
Скачать: CL | DM;
Память: 0.46 MB
Время: 0.036 c