Привет Всем!

Есть СОМ сераер в EXE. У него есть интерфейс IX и proxy/stub dll. Эта dll регистрируется правильно:

HKEY_CLASSES_ROOT
CLSID
{proxy dll GUID}
InprocServer32 c:\ps.dll


Interface
{IX GUID}
ProxyStubClsid32 {proxy dll GUID}

Но при запросе клиентом этого интерфейса, ps.dll не загружается... и возвращается E_NOINTERFACE.
Может кто-то натыкался на подобные горбы? Буду премного благодарет за ответ!

Здравствуйте, Аноним, Вы писали:

А>Привет Всем!

А>Есть СОМ сераер в EXE. У него есть интерфейс IX и proxy/stub dll. Эта dll регистрируется правильно:

А>HKEY_CLASSES_ROOT
А> CLSID
А> {proxy dll GUID}
А> InprocServer32 c:\ps.dll

А>
А> Interface
А> {IX GUID}
А> ProxyStubClsid32 {proxy dll GUID}

А>Но при запросе клиентом этого интерфейса, ps.dll не загружается... и возвращается E_NOINTERFACE.

Где и как объявлен IX в midl'e? Чтобы для него использовались/создавались proxy/stub, он не должен быть объявлен с аттрибутом local и/или быть внутри library блока.
В реестре dll зарегистрирована правильно, но что зарегистрировано для интерфейса? Запусти OLE/COM object viewer, найди в дереве Interfaces свой IX (если он там вообще есть) и посмотри у него ProxyStubClsid.

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

ME>Где и как объявлен IX в midl'e? Чтобы для него использовались/создавались proxy/stub, он не должен быть объявлен с аттрибутом local и/или быть внутри library блока.
ME>В реестре dll зарегистрирована правильно, но что зарегистрировано для интерфейса? Запусти OLE/COM object viewer, найди в дереве Interfaces свой IX (если он там вообще есть) и посмотри у него ProxyStubClsid.

И интерфейс регирстируется правильно, его регистрирует proxy/stub dll.
В ключе ProxyStubClsid32 этого интерфейса прописан CLSID dll. И запись о местонахождении dll тоже правильная. Но вот почему-то не вызывается...... Может что-то с самой dll?

Здравствуйте, Аноним, Вы писали:

хъ

А>И интерфейс регирстируется правильно, его регистрирует proxy/stub dll.
А>В ключе ProxyStubClsid32 этого интерфейса прописан CLSID dll. И запись о местонахождении dll тоже правильная. Но вот почему-то не вызывается...... Может что-то с самой dll?

Нужно отлаживать.

Поставь breakpoint на DllGetClassObject. Проверь, действительно ли загрузилась прокся (окошко output).

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

А>Здравствуйте, Аноним, Вы писали:

А>хъ

А>>И интерфейс регирстируется правильно, его регистрирует proxy/stub dll.
А>>В ключе ProxyStubClsid32 этого интерфейса прописан CLSID dll. И запись о местонахождении dll тоже правильная. Но вот почему-то не вызывается...... Может что-то с самой dll?

А>Нужно отлаживать.

А>Поставь breakpoint на DllGetClassObject. Проверь, действительно ли загрузилась прокся (окошко output).

DLL вообще не загрушается. С помощью regspy я посмотрел, что на запрос этого интерфейса COM находит запись о нем в реестре (Interfaces\{IID_IX}) и ВСЕ! Даже не лезет смотреть в ключ CLSID, где находится запись о proxy/stub CLSID... Мистика какая-то...

А>DLL вообще не загрушается. С помощью regspy я посмотрел, что на запрос этого интерфейса COM находит запись о нем в реестре (Interfaces\{IID_IX}) и ВСЕ! Даже не лезет смотреть в ключ CLSID, где находится запись о proxy/stub CLSID... Мистика какая-то...

1. Приведи содержание раздела реестра HKEY_CLASSES_ROOT\Interface\Твой интерфейс
2. Приведи содержание реестра по HKEY_CLASSES_ROOT\CLSID\Твой интерфейс


ЗЫ: Ты случайно не ручками регестрируешь прокси/стаб Это конечно глупое предположение , но...

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

Tom>1. Приведи содержание раздела реестра HKEY_CLASSES_ROOT\Interface\Твой интерфейс
Tom>2. Приведи содержание реестра по HKEY_CLASSES_ROOT\CLSID\Твой интерфейс

Tom>
Tom>ЗЫ: Ты случайно не ручками регестрируешь прокси/стаб Это конечно глупое предположение , но...

В общем проблему локализовал и убил. Спасибо всем, кто откликнулся!
Теперь расскажу суть, на тот случай, если кто с таким маразмом сталкнется.

Регистрация proxy/stub dll и интерфейса правильная, никаких ошибок... но...
Как вы знаете, когда midl компилирует proxy/stub dll (REGISTER_PROXY_DLL установлен), он выбирает CLSID для этой dll (СОМ объекта имеется в виду) как первый встретившийся IID интерфейса предоставляемый этой dll:

// rpcproxy.h

#define GET_DLL_CLSID   \
    ( aProxyFileList[0]->pStubVtblList[0] != 0 ? \
    aProxyFileList[0]->pStubVtblList[0]->header.piid : 0)

...

// dlldata.c

DLLDATA_ROUTINES( aProxyFileList, GET_DLL_CLSID )

Так вот этим самым первым интерфейсом был интерфейс (IY), который также помещался в typelib и мог быть создан через мой exe сервер. (Это и был баг, этот интерфейс не должен был попадать в proxy/stub dll) И вот какая ситуация: клиент пытается запросить интерфейс IX (см. выше), СОМ ищет IID этого интерфейса в регистри, находит, смотрит ключ ProxyStubClsid32, находит IID интерфейса IY и дальше, он видит, что этот объект создается с помощью моего сервера (не прокси dll), т.к от объявлен в typelib сервера и сервер регистрирует что он создает этот объект. Поэтому СОМ ни разу не обращался в регистри к ключу CLSID моей proxy/stub dll.
Короче грабли!

Здравствуйте, Аноним, Вы писали:

[]

А>Так вот этим самым первым интерфейсом был интерфейс (IY), который также помещался в typelib и мог быть создан через мой exe сервер. (Это и был баг, этот интерфейс не должен был попадать в proxy/stub dll) И вот какая ситуация: клиент пытается запросить интерфейс IX (см. выше), СОМ ищет IID этого интерфейса в регистри, находит, смотрит ключ ProxyStubClsid32, находит IID интерфейса IY и дальше, он видит, что этот объект создается с помощью моего сервера (не прокси dll), т.к от объявлен в typelib сервера и сервер регистрирует что он создает этот объект. Поэтому СОМ ни разу не обращался в регистри к ключу CLSID моей proxy/stub dll.
А>Короче грабли!

Насколько я понял, у тебя грабли в том, что интерфейс и объект, реализующий этот интерфейс имеют один и тот же uuid.

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


ME>Насколько я понял, у тебя грабли в том, что интерфейс и объект, реализующий этот интерфейс имеют один и тот же uuid.

Не совсем, CLSID proxy/stub соответствовал IID'у одного из интерфейсов, предоставляемых сервером [1]. Проблемы была в том, что сервер регистрировал, что он создает объект с таким CLSID. И при попытке создать proxy/stub СОМ определял, что он создается с помощью этого самого сервера... а должен был искать dll в реестре. Я понимаю, что это звучит запутанно, но по другому не получается. Короче мораль — нужно следить, чтобы объекты, которые содержаться в typelib не попадали в proxy/stub.


[1] Это нормальная правктика по умолчанию, меняют CLSID для proxy только в редких случаях, например 2 проекта использующих 1 idl файл.
Вот кусок из msdn, для тех, кто с таким не сталкивался


C-Compiler Definitions for Proxy/Stubs
...
This default registration code uses the GUID of the first interface encountered as the CLSID for registering the entire proxy/stub DLL server. COM later uses this CLSID to locate and load the compiled proxy/stub server for the marshaling of any of the interfaces the server is registered to handle. When an application makes an interface method call that crosses thread, process, or computer boundaries, COM uses the interface identifier registry entry to locate the CLSID registry entry for the proxy/stub marshaling server. It then uses this CLSID to load the server (if it isn't already loaded) so that the interface call can then be marshaled.

Здравствуйте, Аноним, Вы писали:

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

А>Не совсем, CLSID proxy/stub соответствовал IID'у одного из интерфейсов, предоставляемых сервером [1]. Проблемы была в том, что сервер регистрировал, что он создает объект с таким CLSID.

Вот и получается, что IID интерфейса == CLSID компонента, а это — плохо.

Здравствуйте, Аноним, Вы писали:

ME>>Насколько я понял, у тебя грабли в том, что интерфейс и объект, реализующий этот интерфейс имеют один и тот же uuid.

А>Не совсем, CLSID proxy/stub соответствовал IID'у одного из интерфейсов, предоставляемых сервером [1]. Проблемы была в том, что сервер регистрировал, что он создает объект с таким CLSID. И при попытке создать proxy/stub СОМ определял, что он создается с помощью этого самого сервера... а должен был искать dll в реестре. Я понимаю, что это звучит запутанно, но по другому не получается. Короче мораль — нужно следить, чтобы объекты, которые содержаться в typelib не попадали в proxy/stub.

Из твоего предыдущего описания я понял, что в качестве CLSID proxy/stub используется CLSID одного из твоих коклассов. Так?
Покажи полностью IDL.

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

ME>>>Насколько я понял, у тебя грабли в том, что интерфейс и объект, реализующий этот интерфейс имеют один и тот же uuid.

А>>>Не совсем, CLSID proxy/stub соответствовал IID'у одного из интерфейсов, предоставляемых сервером [1]. Проблемы была в том, что сервер регистрировал, что он создает объект с таким CLSID. И при попытке создать proxy/stub СОМ определял, что он создается с помощью этого самого сервера... а должен был искать dll в реестре. Я понимаю, что это звучит запутанно, но по другому не получается. Короче мораль — нужно следить, чтобы объекты, которые содержаться в typelib не попадали в proxy/stub.

Ветка сильно помогла, была аналогичная проблема, я поменял GUID прокси, всё заработало. Только так я и не понял — если не менять GUID прокси, как достать интерфейс, GUID которого совпадает с GUID прокси? Выделенное кстати, не понял. Во-первых, как интерфейс может не попасть в прокси и во-вторых, что делать если он должен попасть в прокси, как в моём случае?