Без регистрации COM взаимодействия и зависимых сборок
Мы работаем над интеграцией большого приложения на основе MFC с несколькими управляемыми (.NET) надстройками. Связь с этими надстройками осуществляется через COM.
Исторически мы только использовали реестр, чтобы сделать эти надстройки доступными (как COM-серверы) для приложения. Но теперь мы пытаемся использовать COM-взаимодействие без регистрации для этого.
Мы бы хотели, чтобы эти надстройки могли располагаться в отдельном каталоге, а не в том, в котором запущено приложение, в идеале где угодно. Но мы, очевидно, сталкиваемся с проблемами при создании экземпляров серверных объектов из-за невозможности разрешить зависимые сборки, которые также находятся в каталоге с DLL-библиотекой COM-сервера.
"Старомодное" COM-взаимодействие обрабатывает это с помощью контекста LoadFrom при загрузке целевой сборки. Но механизм контекста активации, похоже, не делает этого.
Кто-нибудь знает, как заставить это работать? Не ясно, можем ли мы идентифицировать зависимые сборки в манифесте SxS модуля или, возможно, мы можем создать контекст активации по-другому?
Спасибо за любые мысли / советы!
Джефф
5 ответов
Надеюсь, я понимаю проблему, так как я не очень знаком с проектом MFC и его ограничениями. Как насчет "хорошо известного" класса.NET с интерфейсом (постоянно зарегистрированным в приложении MFC), который, в свою очередь, обрабатывает все активацию и создание экземпляров?
Родни
Когда я смотрю на статью " Упрощение развертывания приложений с помощью ClickOnce и COM без регистрации", я замечаю, что в манифесте приложения они ссылаются на имя файла свободной от регистрации библиотеки DLL COM-объекта. Я предполагаю, что это имя файла может быть изменено, чтобы включить каталог или что-то подобное.
Во-вторых, в разделе "Более сложный пример" они включают зависимые COM-объекты в качестве ссылок на свой проект и задают их как изолированные. То есть теперь они также бесплатны при регистрации. Я думаю, что их путь также может быть обновлен.
Есть несколько способов решить эту проблему. Первый шаг, однако, заключается в том, чтобы определить, почему он терпит неудачу. Для этого требуется собрать журнал Fusion с помощью fuslogvw . Используя этот журнал, найдите управляемый COM-сервер и зависимую сборку, которую не удалось загрузить — нам нужно понять контекст, в котором загружается сервер, и это проинформирует нас о том, почему зависимая сборка не удалась.
Решение большого молота, которое будет работать «всегда», если вы можете получить событие достаточно рано, этоAppDomain.AssemblyResolve.
Другой вариант, зависящий от относительной компоновки приложения и COM-сервера, — обновить пути зондирования .
Вы зарегистрировали промежуточные (interop) dll с.net framework?
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\regasm "путь..\AxInterop.xxx.dll" или C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\regasm "путь.. \ Interop.xxx.dll"
С уважением Phani
Откройте командную строку visual studio и попробуйте зарегистрировать сборку с помощью regasm
regasm /tlb:"path"