Мы адаптируем наше относительно сложное приложение на стороне клиента (ActiveX / .net / Delphi / C ++ / COM) для использования SxS для развертывания без администратора и изоляции от старых версий нашего продукта.
Нам удалось достичь этой цели почти для всех наших компонентов в процессе, таких как наш .net ui, Delphi ui и COM-серверы, которые мы используем в процессе, путем составления файла манифеста, в котором описаны все библиотеки, используемые нашим процессом, без регистрации. на клиенте любой из компонентов (почти).
И вот почти часть: в настоящий момент наше приложение вызывает (из его части на C ++) внепроцессный сервер ActiveX (Delphi ActiveX EXE), который, в свою очередь, сам вызывает другой набор внепроцессных серверов ActiveX (сторонние плагины, все, что угодно, Delphi, C ++, все, что угодно, если только оно не находится в процессе ActiveX EXE и реализует наши интерфейсы).
Насколько нам известно SxS не поддерживает внепроцессные серверы ActiveX. И мы не можем использовать эти объекты, как на серверах proc com, в нашем основном процессе, потому что это потребует серьезного переписывания нашего приложения и, что еще хуже, поломки нашего общедоступного API, который используется сторонними инструментами и поставщиками, api перерыв, которого мы не можем допустить.
Мы наткнулись на эту статью, в которой описывается, как IHTMLDocument2 можно извлечь из окна Internet Explorer, запущенного в отдельный процесс. Что заставило нас задуматься об этом подходе:
Мы бы создали вторичное вспомогательное приложение / процесс, который будет запускать ActiveX как на сервере процессов. Затем мы будем использовать LresultFromObject и ObjectFromLresult для передачи ссылки на объект ActiveX со спутника приложение к основному процессу приложения. У вспомогательного приложения будет собственный файл манифеста, который позволит ему работать в режиме SxS.
Такой же подход будет использован для связи между этим Delphi ActiveX EXE и сторонними плагинами AciveX EXE.
Существует альтернативное решение, которое на данный момент мы не предпочитаем по сравнению с предложенным выше, которое заключается в использовании прокси-классов .net remoting и .net com для открытия канала связи между двумя процессами путем перевода com-запроса в .net удаленное взаимодействие и вернемся ко второму процессу.
Итак, возникает вопрос:
- Что вы думаете об этом подходе?
- Видите ли вы лучшее решение проблемы?