Заменить компонент C ++ ActiveX реализацией .NET?

Question

У меня есть управляемое и неуправляемое программное обеспечение, использующее компонент ActiveX, предоставленный третьей стороной, для выполнения некоторых обменов данными, но теперь требуется, чтобы этот обмен данными проходил через мое приложение.

В идеале я бы смог установить компонент .NET, который будет предоставлять точно такой же интерфейс и будет использоваться в качестве замены.

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

• Как лучше всего убедиться, что моя реализация интерфейса на 100% совместима с существующим двоичным объектом?

• Как обеспечить, чтобы приложения использовали мою реализацию интерфейса вместо устаревшей реализации? Это просто вопрос регистрации моей реализации и отмены регистрации устаревшей?

• Как я могу гарантировать, что это «вставная» замена, не требующая изменений в существующем программном обеспечении?

• Как обеспечить, чтобы неуправляемый код мог использовать его без проблем?

Примечание: Я могу потребовать использования .NET 4.0, если это упростит задачу.

Редактировать: Сюда будет перемещена награда Как отладить, почему приложение VB6, использующее мой элемент управления .NET ActiveX, не регистрируется для событий? через 2 дня.

Answer 1

1. Использовать библиотеку типов компонента ActiveX.Импортируйте его с помощью Tlbimp.exe, чтобы получить библиотеку взаимодействия. Возможно, она у вас уже есть, если вы используете этот компонент самостоятельно.Реализуйте свой собственный код, унаследовав интерфейсы в этой библиотеке типов.

2. Ваша реализация должна использовать те же GUID и ProgID, что и компонент ActiveX.Используйте OleView.exe, File + View Typelib и выберите ActiveX DLL, чтобы увидеть GUID.Идентификаторы ProgID сложнее, лучше всего посмотреть, как реестр изменяется с помощью утилиты ProcMon SysInternals, когда вы регистрируете DLL ActiveX в Regsvr32.exe.В конечном итоге, точно такие же изменения должны быть внесены программой Regasm.exe при регистрации замены.

3. Как указано в пункте 2.

4. То же самое,регистрация получает неуправляемый код для использования вместо вас.

Чтобы это сработало, вы действительно должны знать, что делают интерфейсы.Вы не можете заставить это работать, если компонент ActiveX фактически является сервером вне процесса (EXE).

Answer 2

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

Заменяемый объект использует события COM.Когда одно из клиентских приложений (я полагаю, VB6, поскольку depends.exe сообщает мне, что оно использует msvbvm60.dll) создает и использует мою замену, оно не регистрируется ни для одного из событий, и, к сожалению, работает так, что послевызов конкретного метода завершен, клиентское приложение ничего не делает до тех пор, пока не сработает событие.

Примечание: Мой заменяющий элемент управления ActiveX наследуется от System.Windows.Forms.Control и устанавливает MiscOptions 131457 для коклассазаписи реестра в соответствии с предложением http://ondotnet.com/pub/a/dotnet/2003/01/20/winformshosting.html,, причина в том, что заменяемая вещь была честным и добрым элементом управления ActiveX, и я не мог заставить этих существующих клиентов успешно создать экземпляр моего объекта без каких-либо изменений кода, пока я не унаследовализ элемента управления WinForms.

Я пробовал подход, в котором мой coclass объявляет публичные события с тем же именем, что и интерфейс, заданный ComSourceInterfaces, это работает на 100% из приложения C #, использующего AxHost, события инициируются.

Я также попытался реализовать IConnectionPointContainer aи все поддерживающие интерфейсы на моем контроле замены, и это работает на 100% из приложения C #, но в приложении VB оно фактически никогда не пытается Advise() вызвать точку подключения интерфейса приемника клиента, оно только вызывает Unadvise()с недопустимым значением cookie равным 0.

Одна проблема с библиотекой типов, которую я заметил, заключается в том, что я не могу заставить tlbexp.exe экспортировать одно из свойств в интерфейсе coclass как OLE_HANDLE, оно просто заканчиваетсябудучи длинным в TLB, сгенерированном из сборки (на этот TLB ссылается запись TypeLib в реестре).Может ли это вызвать проблемы с обработкой событий?

Есть идеи, как это отладить?