Re[4]: DCOM от А до Я - COM/DCOM/ActiveX

Здравствуйте господа !
У меня вот такой вопрос. Есть DCOM сервер и есть клиент.
Может ли кто-нибудь рассказать или сказать где можно почитать подробно о том,
как провести установку приложений, с использованием DCOM, от начала и до конца.
Т.е. на удаленной машине нужно поставить сервер и потом к нему коннектиться с клиента.

1. Порядок установки сервера. Что сначала запустить, что прописать, что должно быть установлено дополнительно?

2. Настройка клиента. Что сначала запустить, что прописать, что должно быть установлено дополнительно?
Буду ОЧЕНЬ признателен за ответ.
Заранее спасибо.

Здравствуйте Egor, Вы писали:

E>У меня вот такой вопрос. Есть DCOM сервер и есть клиент.
E>Может ли кто-нибудь рассказать или сказать где можно почитать подробно о том, как провести установку приложений, с использованием DCOM, от начала и до конца.

Тут одной установкой не обойдёшься, надо будет ещё и в коде пошаманить.

E>Т.е. на удаленной машине нужно поставить сервер и потом к нему коннектиться с клиента.
E>

1. Порядок установки сервера. Что сначала запустить, что прописать, что должно быть установлено дополнительно?
E>

2. Настройка клиента. Что сначала запустить, что прописать, что должно быть установлено дополнительно?
E>Буду ОЧЕНЬ признателен за ответ.

Вот откапал свой ответ на iXBT:

Устанавливаем одинаковые настройки безопасности на клиенте и сервере, где-нибудь сразу после CoInitialize(Ex):
```
::CoInitializeSecurity(
    0, -1, 0, 0,
    RPC_C_AUTHN_LEVEL_CONNECT,
    RPC_C_IMP_LEVEL_IDENTIFY,
    0, 0, 0 );
```
Регестрируем объект на обоих машинах
Идём в dcomcnfg на сервере.
На вкладке Identity выставляем под каким аккаунтом будет работать сервер:
The interactive user — под аккаунтом того, кто в данный момент топчит клаву (не работает, если никто не залогинился).
The launching user — под аккаунтом того, кто этот объект запустил (не удобно, если надо чтобы с одним объектом работали все пользователи).
This user — создаешь юзера — Mister Object, даёшь ему необходимые права и вперёд.
Дальше вкладка Security:
Use custom access permition — задаёшь тех, кто может работать с объектом.
Use custom launch permition — кто имеет право создавать объект.

Вызов сервера с клиента.

BSTR servnm = L"AppServer";
COSERVERINFO csi = { 0, servnm, 0, 0 };
MULTI_QI mqi = { &__uuidof(IMyInterface), 0, 0 };
HRESULT hr =
    CoCreateInstanceEx(__uuidof(MyInterface),0,CLSCTX_REMOTE_SERVER,&csi,1,&mqi);
if (FAILED(hr)) {
    return 0;
}

... mqi.pItf; ... // здесь указатель на IUnknownm
qi.pItf->Release();

servnm позволяет указывать имя машины на которой будет стартовать сервер.

Здравствуйте IT, Вы писали:

E>>У меня вот такой вопрос. Есть DCOM сервер и есть клиент.
E>>Может ли кто-нибудь рассказать или сказать где можно почитать подробно о том, как провести установку приложений, с использованием DCOM, от начала и до конца.

IT>Тут одной установкой не обойдёшься, надо будет ещё и в коде пошаманить.

Не пугай человека безопасностью. Может, он regsvr32 в лицо не знает.

E>>Т.е. на удаленной машине нужно поставить сервер и потом к нему коннектиться с клиента.
E>>

1. Порядок установки сервера. Что сначала запустить, что прописать, что должно быть установлено дополнительно?
E>>

2. Настройка клиента. Что сначала запустить, что прописать, что должно быть установлено дополнительно?
E>>Буду ОЧЕНЬ признателен за ответ.

IT>Вот откапал свой ответ на iXBT:

IT>

Устанавливаем одинаковые настройки безопасности на клиенте и сервере, где-нибудь сразу после CoInitialize(Ex):

Я расскажу что делать до проблем с безопасностью (все бегает под одним доменным аккаунтом с администраторскими правами, например).

IT>

Регестрируем объект на обоих машинах

Регистируем компонент на сервере. С помощью regsvr32 (см. "Register COM Server") или "<appname> -server". Проверяем, что его можно инстанциировать (с помощью oleview, напрмер).

Устанавливаем клиента на сервере. Проверяем, что клиент работает с сервером.

Регистирируем серверный компонент на клиенте. Идём в dcomcnfg на клиенте. Находим в списке Applicatins сервер-компонет. На вкладке Location ставим, что компонент будует исполняться на сервере (имя сервера), а не на клиентской машине. Проверяем, что серверный объект может быть инстанциирован на сервер с клиентской машины с помощью oleview.

И только потом ставим клиента на клиентской машине и пытаемся работать с сервером.

Если ратотает — повезло. Нет — нужно разбираться с безопасностью.

IT>

Идём в dcomcnfg на сервере.
IT>На вкладке Identity выставляем под каким аккаунтом будет работать сервер:
IT>The interactive user — под аккаунтом того, кто в данный момент топчит клаву (не работает, если никто не залогинился).
IT>The launching user — под аккаунтом того, кто этот объект запустил (не удобно, если надо чтобы с одним объектом работали все пользователи).
IT>This user — создаешь юзера — Mister Object, даёшь ему необходимые права и вперёд.
IT>Дальше вкладка Security:
IT>Use custom access permition — задаёшь тех, кто может работать с объектом.
IT>Use custom launch permition — кто имеет право создавать объект.

Здравствуйте George_Seryakov, Вы писали:

GS> Регистирируем серверный компонент на клиенте. Идём в dcomcnfg на клиенте. Находим в списке Applicatins сервер-компонет. На вкладке Location ставим, что компонент будует исполняться на сервере (имя сервера), а не на клиентской машине. Проверяем, что серверный объект может быть инстанциирован на сервер с клиентской машины с помощью oleview.

Вот не люблю я этот способ. Не люблю и всё, а почему не знаю

Здравствуйте IT, Вы писали:

IT>Здравствуйте George_Seryakov, Вы писали:

GS>> Регистирируем серверный компонент на клиенте. Идём в dcomcnfg на клиенте. Находим в списке Applicatins сервер-компонет. На вкладке Location ставим, что компонент будует исполняться на сервере (имя сервера), а не на клиентской машине. Проверяем, что серверный объект может быть инстанциирован на сервер с клиентской машины с помощью oleview.

IT>Вот не люблю я этот способ. Не люблю и всё, а почему не знаю

Ну тогда

set o = CreateObject("<ProgId>")
msgbox o.<method> <parameters>

Или в dcomcnfg|Applications|Location ходить не любишь? А как же role-based security? Тоже все через код будешь настраивать?

Интересно, бывают ли прсихоаналитики для программеров?

Здравствуйте George_Seryakov, Вы писали:

IT>>Вот не люблю я этот способ. Не люблю и всё, а почему не знаю

Вспомнил почему не люблю. Это надо настраивать на каждом клиенте.

GS>Или в dcomcnfg|Applications|Location ходить не любишь? А как же role-based security? Тоже все через код будешь настраивать?

GS>Интересно, бывают ли прсихоаналитики для программеров?

Да, бывают. Админы, которым надо будет обходить пару сотен рабочих станций и запускать на каждой этот самый dcomcnfg. Обычно это заканчивается продолжительным взглядом глаза в глаза и недвусмысленным покручиванием пальцем у виска.

Мда...
Как обычно ударились в выяснения того, кто кого круче,
кто как любит.

RegSvr32 я знаю / начальник рассказывал

/

А что значит "Проверяем, что его можно инстанциировать (с помощью oleview, напрмер)."
Что надо сделать, ну скачал я oleview. Там набор сишных исходников. И что ? Еше и компилировать надо. Ну совсем дурдом.

Здравствуйте Egor, Вы писали:

E>Мда...
E>Как обычно ударились в выяснения того, кто кого круче, кто как любит.

Бывает, извини

E>RegSvr32 я знаю / начальник рассказывал

/

Мудрый человек.

E>А что значит "Проверяем, что его можно инстанциировать (с помощью oleview, напрмер)."

Это к GS.

E>Что надо сделать, ну скачал я oleview. Там набор сишных исходников. И что ? Еше и компилировать надо. Ну совсем дурдом.

Ну, компилировать его совсем не обязательно, достаточно в студии зайти в Menu->Tools и запустить OLE/COM Object Viewer.

Здравствуйте Egor, Вы писали:

E>Мда...
E>Как обычно ударились в выяснения того, кто кого круче,
E>кто как любит.

E>RegSvr32 я знаю / начальник рассказывал

/

E>А что значит "Проверяем, что его можно инстанциировать (с помощью oleview, напрмер)."
E>Что надо сделать, ну скачал я oleview. Там набор сишных исходников. И что ? Еше и компилировать надо. Ну совсем дурдом.

Да. еше.
Все это я пытаюсь сделать средствами Дельфи.

Здравствуйте IT, Вы писали:

IT>Здравствуйте George_Seryakov, Вы писали:

IT>>>Вот не люблю я этот способ. Не люблю и всё, а почему не знаю

IT>Вспомнил почему не люблю. Это надо настраивать на каждом клиенте.

Не, надо на каждом клиенте installshield запускать. Вот он пусть все это настраивает.

GS>>Интересно, бывают ли прсихоаналитики для программеров?

IT>Да, бывают. Админы, которым надо будет обходить пару сотен рабочих станций и запускать на каждой этот самый dcomcnfg. Обычно это заканчивается продолжительным взглядом глаза в глаза и недвусмысленным покручиванием пальцем у виска.

Программу написать. Скриптец — на случай настройки location. Если админ такого не умеет — пусть ходит.

Не принимается.

Здравствуйте George_Seryakov, Вы писали:

IT>>Да, бывают. Админы, которым надо будет обходить пару сотен рабочих станций и запускать на каждой этот самый dcomcnfg. Обычно это заканчивается продолжительным взглядом глаза в глаза и недвусмысленным покручиванием пальцем у виска.

GS>Программу написать. Скриптец — на случай настройки location. Если админ такого не умеет — пусть ходит.

GS>Не принимается.

Мда... не видел ты моего админа... Будешь в FL — заходи, покажу.

/

Так, может, пусть он DCOM и настраивает?

E>А что значит "Проверяем, что его можно инстанциировать (с помощью oleview, напрмер)."
E>Что надо сделать, ну скачал я oleview. Там набор сишных исходников. И что ? Еше и компилировать надо. Ну совсем дурдом.

Не, компилировать не надо. Это уже откомпилированная тулза. Oleview входит в состав Visual Studio и NT Option Pack 4.
См "Using the OLE/COM Object Viewer". Если мышкой кликнуть на к-нить объект, то потом можно через меню Object|Create Instance его скриэйтить. Там еще и Location посмотреть/изменить можно. Учи матчасть, короче. Тебе еще с безопасностью разбираться.

Здравствуйте Egor, Вы писали:

E>Здравствуйте Egor, Вы писали:

E>>Мда...
E>>Как обычно ударились в выяснения того, кто кого круче,
E>>кто как любит.

E>>RegSvr32 я знаю / начальник рассказывал

/

E>>А что значит "Проверяем, что его можно инстанциировать (с помощью oleview, напрмер)."
E>>Что надо сделать, ну скачал я oleview. Там набор сишных исходников. И что ? Еше и компилировать надо. Ну совсем дурдом.

E>Да. еше.
E>Все это я пытаюсь сделать средствами Дельфи.

Настройки DCOM делаются без программирования. Oleview возьми с какого-нибудь компьютера, где есть Visual Studio.

Здравствуйте George_Seryakov, Вы писали:

GS>Настройки DCOM делаются без программирования.

До тех пор пока у клиента есть права администратора.

Ребята, вы еще тут?

Вообщем я настроил эту штуку (кажется)

Прописал юзера на серваке.
Запустил dcomcnfg, установил там все security.
Теперь у меня компонент DCOMConnection коннектится.
А вот ClientDataSet при попытке установить свойство Active = true
выдает Error loading type library/DLL

Что это может быть ?

Здравствуйте Egor, Вы писали:

E>А вот ClientDataSet при попытке установить свойство Active = true выдает Error loading type library/DLL

E>Что это может быть ?

А ты удалённый компонент (тот который должен стартовать на сервере) на клиентской машине зарегистрировал?

Здравствуйте IT, Вы писали:

IT>Здравствуйте Egor, Вы писали:

E>>А вот ClientDataSet при попытке установить свойство Active = true выдает Error loading type library/DLL

E>>Что это может быть ?

IT>А ты удалённый компонент (тот который должен стартовать на сервере) на клиентской машине зарегистрировал?

Конечно, запускаю dcomcnfg и вижу его в списке. Затем его же и конфигурирую, т.е. указываю ему стартовать на таком-то сервере.
А на сервере ему указываю стартовать локально.
Сервер у меня сделан в виже .exe файла. Но я думаю это роли не играет, хоть это .ехе или dll.

Здравствуйте IT, Вы писали:

GS>>Программу написать. Скриптец — на случай настройки location. Если админ такого не умеет — пусть ходит.

GS>>Не принимается.

IT>Мда... не видел ты моего админа... Будешь в FL — заходи, покажу.

А что такое? Неуставные отношения?

Здравствуйте IT, Вы писали:

IT>Здравствуйте George_Seryakov, Вы писали:

GS>>Настройки DCOM делаются без программирования.

IT>До тех пор пока у клиента есть права администратора.

Это так. Но если мы хотим иметь фашистское администрирование, то админу придется побегать. Конечно, можно обойти непрописанные в реджистри настройки дикома захардкоживая их в исходные тексты, но
не дело это. Вот у меня с пяток разных серверных инсталляций (на разных стадиях тестирования/интеграции), в разных местах США. И что, мне пять разных кодов собирать?

Здравствуйте Egor, Вы писали:

E>Ребята, вы еще тут?

E>Вообщем я настроил эту штуку (кажется)

E>Прописал юзера на серваке.
E>Запустил dcomcnfg, установил там все security.
E>Теперь у меня компонент DCOMConnection коннектится.
E>А вот ClientDataSet при попытке установить свойство Active = true
E>выдает Error loading type library/DLL

E>Что это может быть ?

Все претензии разработчикам ClientDataSet.

Попробуй выснить какую библиотеку он не может загрузить. Воспользуйся RegMon с SysInternals.com. Сравни библиотеку и ее регистрацию на сервере и клиенте.

Здравствуйте Egor, Вы писали:

E>Ребята, вы еще тут?

E>Вообщем я настроил эту штуку (кажется)

E>Прописал юзера на серваке.
E>Запустил dcomcnfg, установил там все security.
E>Теперь у меня компонент DCOMConnection коннектится.
E>А вот ClientDataSet при попытке установить свойство Active = true
E>выдает Error loading type library/DLL

E>Что это может быть ?

Это наверно Midas.dll не зарегистрен на клиентской машине. :-\

Здравствуйте George_Seryakov, Вы писали:

GS>Это так. Но если мы хотим иметь фашистское администрирование, то админу придется побегать. Конечно, можно обойти непрописанные в реджистри настройки дикома захардкоживая их в исходные тексты, но
GS>не дело это. Вот у меня с пяток разных серверных инсталляций (на разных стадиях тестирования/интеграции), в разных местах США. И что, мне пять разных кодов собирать?

В моём примере:

BSTR servnm = L"AppServer";
COSERVERINFO csi = { 0, servnm, 0, 0 };

"AppServer" объявлен отдельной переменной совсем неспроста. Имя сервера можно прочитать из реестра, ini-файла, откуда угодно и никакого хардкода, и админу бегать не надо. А позиция "пусть бегает, это его работа" мягко говоря неразумна.

Здравствуйте IT, Вы писали:

IT>В моём примере:

IT>

IT>BSTR servnm = L"AppServer";
IT>COSERVERINFO csi = { 0, servnm, 0, 0 };
IT>

IT>"AppServer" объявлен отдельной переменной совсем неспроста. Имя сервера можно прочитать из реестра, ini-файла, откуда угодно и никакого хардкода, и админу бегать не надо.

Имя сервера должно находиться в поле RemoteServerName в реджистри. И использоваться при вызове CCI без указания где криэйтать. Нужны очень веские основания, чтоб не пользоваться такой схемой и невозможность/нежелание вызвать dcоmcnfg за отмазку не катит. ИМХО.
За отмазку катила бы необходимость работать с несколькими серверами одновременно или с несколькими в пределах одного сеанса запуска клиентского приложения.

IT>А позиция "пусть бегает, это его работа" мягко говоря неразумна.

Пусть бегает если не умеет не бегать.

Здравствуйте George_Seryakov, Вы писали:

GS> Имя сервера должно находиться в поле RemoteServerName в реджистри. И использоваться при вызове CCI без указания где криэйтать. Нужны очень веские основания, чтоб не пользоваться такой схемой и невозможность/нежелание вызвать dcоmcnfg за отмазку не катит. ИМХО.

Представь себе, я уже забыл когда запускал dcomcnfg на клиенте. Имя сервера устанавливается одной строчкой в ini-файле. Причём (обрати внимание!!!) сразу для всех клиентов, будь их 10, 100 или 1000. Хотя, конечно обслуживать программу получается слишком просто. А программа, которая тихо работает за серьёзную не считается. Я понимаю.

GS> За отмазку катила бы необходимость работать с несколькими серверами одновременно или с несколькими в пределах одного сеанса запуска клиентского приложения.

Ну я частенько переключаюсь между отладочным сервером и рабочим.

IT>>А позиция "пусть бегает, это его работа" мягко говоря неразумна.

GS> Пусть бегает если не умеет не бегать.

Всё. Вопросов больше нет.

PS. Take it easy

Нам ещё Outlook к RSDN надо прикрутить.

Здравствуйте IT, Вы писали:

IT>Здравствуйте George_Seryakov, Вы писали:

GS>> Имя сервера должно находиться в поле RemoteServerName в реджистри. И использоваться при вызове CCI без указания где криэйтать. Нужны очень веские основания, чтоб не пользоваться такой схемой и невозможность/нежелание вызвать dcоmcnfg за отмазку не катит. ИМХО.

IT>Представь себе, я уже забыл когда запускал dcomcnfg на клиенте. Имя сервера устанавливается одной строчкой в ini-файле. Причём (обрати внимание!!!) сразу для всех клиентов, будь их 10, 100 или 1000.

Совершенно аналогично. Только строчка в ini читается один раз — при установке. И сразу прописывается в registry.

IT>Хотя, конечно обслуживать программу получается слишком просто. А программа, которая тихо работает за серьёзную не считается. Я понимаю.

Была у меня в свое время мысль по написанию распределенной утилиты конфигурирования распределенных систем. Потом я почитал про Active Directories и мысль эта ушла. К чему это я? Ах, да. Стандартными средствами пользоваться надо.

IT>>>А позиция "пусть бегает, это его работа" мягко говоря неразумна.

GS>> Пусть бегает если не умеет не бегать.

IT>Всё. Вопросов больше нет.

Нее, вопросы есть. Если админ не знает, придется программерам искать: как проставить в данное место реджистри значение удаленной машины для данного кокласса (или группы оных). Active Directories есть, еще что? Была какая-то zero administration... Программу можно написать, чтоб она устанавливала себе необходимые полномочия и таки писала в registry. Какие еще идеи?

IT>PS. Take it easy

Нам ещё Outlook к RSDN надо прикрутить.

А на раз. Как там у вас дела с CDO продвигаются? Может, поставить таки ньюссервер, но наружу его через другое прокси пускать поверх HTTP?

Здравствуйте George_Seryakov, Вы писали:

IT>>Представь себе, я уже забыл когда запускал dcomcnfg на клиенте. Имя сервера устанавливается одной строчкой в ini-файле. Причём (обрати внимание!!!) сразу для всех клиентов, будь их 10, 100 или 1000.

GS> Совершенно аналогично. Только строчка в ini читается один раз — при установке. И сразу прописывается в registry.

Понятно. А при замене сервера в любом случае нужно перезагрузить все клиентские машины, особенно если у юзеров нет прав записи в реестр.

GS>Была у меня в свое время мысль по написанию распределенной утилиты конфигурирования распределенных систем. Потом я почитал про Active Directories и мысль эта ушла. К чему это я? Ах, да. Стандартными средствами пользоваться надо.

Одно другому не мешает. CoCreateInstanceEx не менее стандартна чем dcomcnfg.

GS>>> Пусть бегает если не умеет не бегать.

IT>>Всё. Вопросов больше нет.

GS>Нее, вопросы есть. Если админ не знает, придется программерам искать: как проставить в данное место реджистри значение удаленной машины для данного кокласса (или группы оных). Active Directories есть, еще что? Была какая-то zero administration... Программу можно написать, чтоб она устанавливала себе необходимые полномочия и таки писала в registry. Какие еще идеи?

Вообще ничего в registry не писать. Чем не идея?

Здравствуйте IT, Вы писали:

IT>PS. Take it easy

Нам ещё Outlook к RSDN надо прикрутить.
А в какой стадии сие начинание? А то в треде по NNTP никакой активности (да и на sf.net/projects/rsdn2nntp аналогично)...
К чему в принципе пришли?

Здравствуйте bormant, Вы писали:

B>Здравствуйте IT, Вы писали:

IT>>PS. Take it easy

Нам ещё Outlook к RSDN надо прикрутить.
B>А в какой стадии сие начинание? А то в треде по NNTP никакой активности (да и на sf.net/projects/rsdn2nntp аналогично)...

Надо бы сырцы туда положить... Немного стыдно ну да ладно.

B>К чему в принципе пришли?

Есть туннелятор NNTP в HTTP, клиентская сторона. Ну, так, в принципе, работает. Теперь проблема сделать ответный сервер.

Здравствуйте George_Seryakov, Вы писали:
B>>К чему в принципе пришли?
GS>Есть туннелятор NNTP в HTTP, клиентская сторона. Ну, так, в принципе, работает. Теперь проблема сделать ответный сервер.
Извиняюсь за возможно излишнюю назойливость...
т.е. порт наружу Вам никто не дает :( А "ответчик" как делать планируете? В HTTP заворачивать NNTP? Или уже какие новые мысли на сей счет нарисовались?

Здравствуйте IT, Вы писали:

IT>Да, бывают. Админы, которым надо будет обходить пару сотен рабочих станций и запускать на каждой этот самый dcomcnfg. Обычно это заканчивается продолжительным взглядом глаза в глаза и недвусмысленным покручиванием пальцем у виска.

А этот программист про инсталляторы не слышал? Или на худой конец сам админ может слышал о скриптах регэдита?

Здравствуйте IT, Вы писали:

IT>Мда... не видел ты моего админа... Будешь в FL — заходи, покажу.

А он у вас так, что Американец что ли?

Здравствуйте IT, Вы писали:

IT>Представь себе, я уже забыл когда запускал dcomcnfg на клиенте. Имя сервера устанавливается одной строчкой в ini-файле. Причём (обрати внимание!!!) сразу для всех клиентов, будь их 10, 100 или 1000. Хотя, конечно обслуживать программу получается слишком просто. А программа, которая тихо работает за серьёзную не считается. Я понимаю.

Т.е. ini-файл у тебя на сети лежит?

Здравствуйте IT.

А не пробывал инсталляторы от COM+? Можно устанавливать средствами W2k-рем.инст. или программно. При этом конфигурируется не тлько имя сервера, но и все что захочешь.

Здравствуйте VladD2, Вы писали:

IT>>Да, бывают. Админы, которым надо будет обходить пару сотен рабочих станций и запускать на каждой этот самый dcomcnfg. Обычно это заканчивается продолжительным взглядом глаза в глаза и недвусмысленным покручиванием пальцем у виска.

VD>А этот программист про инсталляторы не слышал? Или на худой конец сам админ может слышал о скриптах регэдита?

Да понятно это всё. Только чтобы писануть чего-нибудь в реестр нужно как минимум иметь для этого соответствующие права. А прав этих у юзеров нет и никогда не будет. Политика партии, понимаешь. Да и правильно это, ихнее дело кнопки нажимать, а не права иметь. Для того, чтобы записать что-нибудь в реестр (например, поставить новый компонент) нужно перегрузить клиентский компьютер, присутствие админа при этом не нужно. Но это надо сделать на сотнях компутеров, т.е. остановить на какое-то время делопроизводство. Иногда это делается при замене софта. Но такая мелочь как смена application server

часто этого не требует.

Это первое. Второе. Что бы вы мне не рассказвали про тупых админов и бестолковых юзеров, но я никогда не соглашусь с тем, что лучше что-то не доделать (или не сделать по уму) и пуcть бегают другие, т.к. им за это деньги платят. Не соглашусь по простой причине: а на хрена тогда мы нужны?

Здравствуйте VladD2, Вы писали:

VD>Т.е. ini-файл у тебя на сети лежит?

Точно.

Здравствуйте IT, Вы писали:

IT>... т.к. им за это деньги платят. Не соглашусь по простой причине: а на хрена тогда мы нужны?

Я?

Здравствуйте IT, Вы писали:

IT>Одно другому не мешает. CoCreateInstanceEx не менее стандартна чем dcomcnfg.

А кстати, CreateObject(<ProgId>, <ServerName>) — она насколько CoCreateInstanceEx?

Про CreateObject мы тут обнаружили интересную вещь: Есть система, где используется много одинаковых объектов (и, соответственно, адреса серверов не лежат в RemoteMachineName, а, напротив, список находится в специальном хранилище). В этом случае, когда вызываешь CreateObject с явно указанным именем машины исполнения, причем таким, что это имя локальной машины, так вот в этом случае DCOM способен отфорвардить вызов по RemoteMachineName, если он указан.

Кто знает, для CoCreateInstanceEx поведение такое же, то есть это все штучки DCOM? или все-таки это реализация CreateObject?

Привет всем!
Вобщем я тут кое-что настроил.
1.Написал DCOM сервер в виде .ехе файла.
Установил его на серваке, прописал ему security.
Для того чтобы все заработало еще надо было скинуть на сервер midas.dll.
Скинул midas.dll, зарегистрировал — вот теперь полный коннект!!!
Теперь я решил сделать DCOM сервер в виде dll. Сделал, локально все работает,
а вот удаленно никак. Получаю — Class not Registered. Хотя везде эту dll зарегистрировал
и у себя и на удаленном серваке. И еще security для dll не выставляются,
Вообще такой закладки нет в dcomcnfg.
Есть ли у кого какие соображения на этот счет?
2.Может кто расскажет как настроить клиентскую часть без запуска dcomcnfg.
Желательно рассказать подробнее, типа для чайников. Я тут почитал ответы,
честно говоря мало что понял. Я так понимаю, что серверную часть на клиентской машине
всеравно регистрировать придется. А так нельзя сделать, чтобы
на свежей машине, которую только что поставили, запустил клиент свой клиентский экзешник и вперед?

Заранее благодарен за ответ !

Здравствуйте Egor, Вы писали:

E> Теперь я решил сделать DCOM сервер в виде dll. Сделал, локально все работает,
E> а вот удаленно никак. Получаю — Class not Registered. Хотя везде эту dll зарегистрировал
E> и у себя и на удаленном серваке. И еще security для dll не выставляются,
E> Вообще такой закладки нет в dcomcnfg.
E> Есть ли у кого какие соображения на этот счет?

dcomcnfg и вообще удаленная активизация возможны только для Application, каковым dll не является. Проще всего — положить твой компонент под MTS (aka COM+). Просто создаешь Package (Application в терминах COM+) и вставляешь туда твой dll. Как регистировать Package на клиентской машине — почитай в документации.

E>2.Может кто расскажет как настроить клиентскую часть без запуска dcomcnfg.

IT тебе изложил уже, в самом начале.

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

Вроде, можно. QI на удаленную машину с данным ClsId не требует регистрации этого ClsId локально.

Здравствуйте George_Seryakov, Вы писали:

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

GS> Вроде, можно. QI на удаленную машину с данным ClsId не требует регистрации этого ClsId локально.

Сомневаюсь, нужно зарегистрировать как минимум библиотеки типов для маршалинга.

Здравствуйте IT, Вы писали:

IT>Здравствуйте George_Seryakov, Вы писали:

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

GS>> Вроде, можно. QI на удаленную машину с данным ClsId не требует регистрации этого ClsId локально.

IT>Сомневаюсь, нужно зарегистрировать как минимум библиотеки типов для маршалинга.

Да, так. Это я лажанулся.

А нельзя как-то в клиента вклеить маршаллирующий код, чтоб маршаллить без DCOM-а? Или все равно без того, чтоб дать знать об этом DCOM-у не обойтись?

	От:	Egor
	Дата:	31.01.02 00:27
	Оценка:

От:	IT	linq2db.com
Дата:	31.01.02 01:56
Оценка:

	От:	George_Seryakov
	Дата:	31.01.02 03:35
	Оценка:

От:	IT	linq2db.com
Дата:	31.01.02 03:42
Оценка:

	От:	George_Seryakov
	Дата:	31.01.02 04:00
	Оценка:

От:	VladD2	www.nemerle.org
Дата:	01.02.02 20:29
Оценка: