Как упоминал Кристофер, InstallShield извлекает информацию COM из вашего .ocx, просматривая то, что она регистрирует, когда вызывается аналогично regsvr32.exe, и будет вызывать ее.Его различные формы перенаправления (для целей захвата) имеют дополнительное преимущество, заключающееся в обходе нескольких потенциальных проблем с разрешениями во время регистрации файла в вашей среде сборки.Однако, если я не пропущу суть вашего вопроса, это «почему regsvr32.exe your.ocx не работает на целевой машине?»
Это немного укол в темноте, как вы не поняли 'т включил достаточно информации.Хотя отсутствующие зависимости могут быть причиной этого, я предполагаю, что вы видите этот сбой только в Windows Vista / Server 2008 или более поздней версии.Если это так, есть большая вероятность, что ваше приложение пытается записать данные в разделы реестра, которые защищены Windows Resource Protection (WRP), или у вас возникла проблема с регистрацией библиотек типов для пользователя.
Когда подпрограмма саморегистрации с плохим поведением сталкивается с WRP, она пытается записать в раздел реестра, который не имеет разрешения на изменение, а затем не проходит всю регистрацию.Я не уверен, что случится с ключами, которые он написал до этого момента, но все те, кто после этого определенно не дойдут до машины.Вы должны быть в состоянии подтвердить, так ли это с таким инструментом, как Process Monitor .
Что вы делаете, если это так?Ну, вы можете придерживаться подхода извлечения, подобного InstallShield (который, как вы говорите, вы хотите оставить).Вы можете исправить файл так, чтобы он не пытался записывать на защищенные ключи (которые, как вы говорите, не можете изменить).Или вы могли бы использовать Application Compatibility Toolkit (ACT) для упрощения работы, но я не понимаю, как вы вообще можете сделать это в нисходящем направлении.Вообще говоря, я бы порекомендовал исправить файл или продолжать использовать рабочий подход.