Каморка

VC++ 6.0 sp3

Все работало раньше по след схеме. Наш DLL сожержит имплементацию каких-то классов, он линкуется с нашим OCX, OCX используется нашим EXE. Setup во время установки все копировал, потом регистрировал OCX и успешно заканчивался.

Теперь мы вынуждены использовать еще один DLL (open source) - Pathlan.dll и линковать его с нашем старом DLL. Мы сами компилируем Pathlan.dll, но во время setup-а при регистрации нашего старого OCX LoadLibrary получает ошибку 0xC0000090.

Самое непонятное - после неуспешной регистрации нашим setup-ом наш OCX успешно регистрируется через regsvr32.exe

Что делать ?

[quote="dima"][/quote]
Если мне не изменяет память, RegisterServer или RegisterObject функция DLL вызывается при регистрации - вся премудрость.

1. Вы что именно делаете, как именно регистрируете? Какая функция "высунута наружу" из DLL? Как насчёт попробовать её из маленького тестового EXE вызывать? LoadLibrary, понеслась...

2. Как насчёт посмотреть исходный текст regsvr32, где-то в SDK? кажись, там, но...

3. Что значит "линковать" DLL с другим DLL? Такое в природе возможно, если не dynamically (само слово DLL...)? Или с LIB? А функция RegisterXXXX не перекрывается при линовке?

Woozy писал(а):

dima писал(а):

Если мне не изменяет память, RegisterServer или RegisterObject функция DLL вызывается при регистрации - вся премудрость.

1. Вы что именно делаете, как именно регистрируете? Какая функция "высунута наружу" из DLL? Как насчёт попробовать её из маленького тестового EXE вызывать? LoadLibrary, понеслась...

2. Как насчёт посмотреть исходный текст regsvr32, где-то в SDK? кажись, там, но...

3. Что значит "линковать" DLL с другим DLL? Такое в природе возможно, если не dynamically (само слово DLL...)? Или с LIB? А функция RegisterXXXX не перекрывается при линовке?

мы в setup вставили вызов нашего спец EXE, который регистрирует наши компоненты и пишет лог файл об успехе или код ошибки принеуспехе. Код регистрации был скопирован с исходников regsvr32.exe

"Линковать dll". Возможно я выразился не правильно. Смысл - DLL экспортирует классы, другая DLL использует эти классы и имеет имя первой DLL (c расширенеем LIB конечно-же) в своем imake файле в "разделе" внешних библиотек.

Про маленький exe - идея не плохая .....

dima писал(а):Про маленький exe - идея не плохая .....

Да, но вы это вроде уже сделали, воспроизведя regsvr32... Что внутри происходит, под отладчиком?

Woozy писал(а):

dima писал(а):Про маленький exe - идея не плохая .....

Да, но вы это вроде уже сделали, воспроизведя regsvr32... Что внутри происходит, под отладчиком?

в Debug setup-а нет. а так все регистрируется без проблем ....

dima писал(а):в Debug setup-а нет. а так все регистрируется без проблем ....

Непонятно, что не даёт добраться до кода под отладчиком, если можно менять сам код и "оживить" его для Debug.

Woozy писал(а):

dima писал(а):в Debug setup-а нет. а так все регистрируется без проблем ....

Непонятно, что не даёт добраться до кода под отладчиком, если можно менять сам код и "оживить" его для Debug.

Проблему решили вот как.
В опциях компиляции злощастной DLL “Pentium Pro” поменяли на “Blend*”

А-БАЛ-АЕТЬ !

dima писал(а):Проблему решили вот как.
В опциях компиляции злощастной DLL “Pentium Pro” поменяли на “Blend*”

А-БАЛ-АЕТЬ !

Это шаманство и не гарантированное решение проблемы. Поскольку не понимаете, из-за чего не работало. Следующий раз, когда не сработает, будете снова с той же проблемой разбираться.

след раза не будет ! Эта библиотека будет заменена на другую.

2 aldep
1. Woozy прав. Или разбираться, или не разбираться.
Если не разобраться, то в будущем обязательно, что-то будет.
2. Немного схожая ситуация с инвалидэйтом в одном из здешних топиков. Только ***хаем себя здесь иначе.

В том, что Вы написали, про то, как setup обламывается при попытке зарегистрировать COM-сервер, ясным по чёрному видно, что скорее всего COM - сервер не грузится вообще в адресное пространство setup-a в обновлённой его версии. Раз он не грузится, то SMS не может сделать callback вызов STDAPI DllRegisterServer(void) экспортируемой первой DLL (та, что работала в самом начале в первой версии), и как следствие не может зарегистрировать CLSID, PROGID в реестре.
А происходит это от того, что скорее какой-то умник или статически вяжет DLL, или неверно задаёт пути до второй DLL. Скорее всего второе, т.к. в первом случае, если setup писан не руками (я думаю, что до этого ещё дело не дошло) присутствовала бы хоть какая-нить обработка ошибок. В первом случае (т.н. раннее связывание) "вызывающий процесс" будет просто валиться по загрузке со всеми вытекающими последствиями в части регистрации COM-сервера.

vg писал(а):2 aldep
1. Woozy прав. Или разбираться, или не разбираться.

А я тут причем? Я молчал.
Тут вообще удаленно не разобраться, надо сесть и продебагать код пол часа, а не в конфе спрашивать.

2aldep
O!!! Sorry! My bad.

Я прошу прощения, aldep. Я торопился, когда постил. Я даже перепутал там в попыхах в конце (вернее, первое назвал вторым и наооборот) в своём постинге замечания о способах загрузки DLL, из-за которой валится setup. Примите мои извинения. С другой стороны, видите какая Вы популярная личность, что на автомате даже вылетает "aldep" вместо Дмитрия. Разве это плохо

а чем вам стандартные инсталяторы не подошли ?

Lepsik, ты шо не догоняешь?
Это может быть и WiseInstallMaster8.14. Если не верно прописан скрипт, то ты хоть застрелись.

ПС. Leosik, если пользуешься инстолшилд от Борланда, то даже не грузись. Ты в корень-то смотри проблемы.