Доступ к x86 COM из x64 .NET

У меня есть сервер x64, который, поскольку мои библиотеки скомпилированы в AnyCPU, работает под управлением x64. Нам нужен доступ к COM-компоненту, который зарегистрирован под x86. Я не знаю достаточно о COM, и мои поиски в Google ни к чему меня не ведут.

Вопрос: Могу ли я использовать символическую ссылку реестра от x64 до x86 для компонента COM? Нужно ли регистрировать COM-компонент под x64? Могу ли я (любое заявление здесь ...)?

Спасибо.

11.12.2008 13:25:43
3 ОТВЕТА
РЕШЕНИЕ

Если компонент работает под управлением x64-native, он не может загрузить 32-битный COM-сервер в процессе, потому что это неправильный процесс. Есть несколько возможных решений:

  1. Если вы можете, создайте 64-битную версию кода COM (который, конечно, будет зарегистрирован в 64-битном реестре). Это самое чистое решение, но оно может оказаться невозможным, если у вас нет кода для COM-сервера.

  2. Запустите ваш .NET-компонент как 32-разрядную версию x86 вместо x64. Я предполагаю, что вы уже рассмотрели и отклонили это по какой-то причине.

  3. Разместите компонент COM вне процесса, используя суррогат COM DLLhost.exe. Это сделает вызовы к COM-серверу намного, намного медленнее (теперь они будут межпроцессными сообщениями Windows вместо вызовов собственных функций), но в остальном прозрачна (вам не нужно делать ничего особенного).

    Это, вероятно, не будет возможным, если серверу требуется пользовательская заглушка прокси вместо обычной oleaut32 (хотя и очень редко), поскольку 64-разрядная версия прокси не будет доступна. Пока он может использовать обычный OLE-маршаллинг, вы можете просто зарегистрировать его для суррогатной активации .

29
11.12.2008 14:04:00
# 1 невозможно, так как нет версии для x64. # 2 побеждает цель запуска на x64. № 3 работал отлично. Мы можем жить с хитами производительности здесь, пока мы не получим новую версию библиотеки. Спасибо за вашу помощь.
Craig Wilson 11.12.2008 14:29:56
@puetzk в моем случае я использую стороннюю DLL, которая установлена ​​как часть другого приложения. У меня нет контроля над сборкой. В таком случае, как я могу использовать суррогатную функцию COM? Спасибо
MeTitus 7.12.2018 17:07:33
@MeTitus, вам придется самостоятельно добавлять записи в реестр, и координация версий может быть сложной, но это все же возможно.
puetzk 19.12.2018 16:57:56
@puetzk В итоге я пошел по другому маршруту. Спасибо за ответ. Счастливого Рождества.
MeTitus 20.12.2018 09:27:45

Если ваш COM-компонент размещен на COM-сервере (то есть в отдельном процессе), вам не нужно делать ничего особенного, поскольку подсистема COM будет переадресовывать ваши вызовы из приложения x64 в приложение X86 и обратно.

Если ваш компонент является внутрипроцессным COM-компонентом, вам придется переосмыслить это, поскольку 64-битный процесс не может использовать 32-битный в COM-компонентах процесса. Вы можете заставить свой сервер работать под x86, чтобы иметь доступ к компонентам (они оба будут 32-битными процессами). Если вы не хотите этого делать, вам придется посмотреть, есть ли у вас 64-битная версия COM-компонентов, которые вы используете.

2
3.06.2011 15:44:33

Я нашел это решение. Работа с устаревшими 32-битными компонентами в 64-битной Windows приведена в статье:
• Преобразование типа проекта из незавершенного в процесс
• Использование COM + в качестве хоста (это работает для меня)
• Использование dllhost в качестве суррогатного хоста

7
3.06.2015 18:15:47