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

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

VD>>1. Не помещай tlb в ресурсы сервера.

IT>Можно здесь поподробнее? Что имеется ввиду и почему?

Можно и по подробнее, но тогда это получится, как минимум FAQ.
Так что предложи кому ни будь это дело отшлифовать и кинуть в факи.

Итак начнем по порядку. Для вызова методов удаленного COM-объекта нужно чтобы на клиентской стороне были выполнены следующие условия:
1) Имелась зарегистрированная proxy/stab-DLL

2) или библиотека была совместима с oleautomation и была зарегистрирована tlb-содержащая описание этого COM-объекта, его типов и интерфейсов.

3) или вызов должен осуществляться через IDispathc-интерфейс.

Примечание:
В первом и втором случае имя сервера может быть указано как при регистрации компонента, так и при создании объекта (на C++ это делается через CoCreateInstaceEx, на VB берез CreateObject). Во втором, нужно обязательно указывать имя метода при создании объекта.

tlb во втором случае заменяет proxy/stab-DLL. На сегодня это самый простой, удобный и гибкий способ вызвать удаленный объект. Регистрацию tlb на клиентской системе можно делать и вручную, но это сложно и дико не удобно. MTS и COM+ поддерживают регистрацию объектов tlb которых вынесено в отдельный файл. COM+, к этому, научился создавать инсталляторы proxy-приложений, которые можно лугко установить на любую версию Windows начиная с 4-ой. При этом на NT 4 лучше установить SP6a (или выше, если такой появится), на 9x DCOM9x.
Если при регистрации COM-сервера его tlb находилась в отдельном файле и не была зарегистрирована proxy/stab-DLL, COM+ кладет в proxy не саму DLL, а tlb.
Это удобно так как позволяет уменьшить размер редистребута и избежать проблем с зависимостью от дополнительных DLL которые требуются самому COM-объекту.

Теперь о том как добиться того, чтобы tlb не входила в состав DLL-модуля в COM-сервера.
В давние времена, когда COM-объекты писали ручьками, такой вопрос не мог даже возникнуть. Ведь регистрацию, как и все остальное, мы писали сами. Но теперь без помощи ATL, VB, VCL, а иногда даже MFC мало кто решиться на написание COM-объектов. Так вот как вынести tlb на всем кроме ATL я не знаю, а на ATL это проще простого. Честно говоря, я уже давно пришел к мнению, писать COM-объекты на чем-то кроме VB, C# (для компонентов бизнес логики) и ATL-е (на C++) – это извращение. Ну да ладно. :)

Все что нужно сделать в ATL-проекте для выноса tlb – это закоментарить (или вычистить) вхождение tlb-файла в файле описания ресурсов (xxx.rc) и копировать tlb-файл в Output-директорию (сделать это проще всего в Custom build step).

ATL (если мне не изменяет память) при регистрации DLL (вызове у нее DllRegisterServer, или как там ее) ищет tlb в ресурсах и если не находит, пытается открыть ее как файл лежащий в той же директории. Далее он вызывает стандартные функции регистрации библиотеки типов.

Я читал, но не проверял, что в Enterprise-версии VB есть возможность полу-ручной регистрации DLL-ей, позволяющей зарегистрировать на клиенте только tlb. .Net вообще всегда кладет tlb-файл отдельно.

Вот собственно и все.