Доступ к x86 COM из x64 .NET
У меня есть сервер x64, который, поскольку мои библиотеки скомпилированы для AnyCPU, работает под x64. Нам нужен доступ к COM-компоненту, зарегистрированному под x86. Я недостаточно знаю о COM, и мои поиски в Google ни к чему не приводят.
Вопрос: Могу ли я использовать символьную ссылку реестра с x64 обратно на x86 для COM-компонента? Нужно ли мне также регистрировать COM-компонент под x64? Могу я (любое заявление здесь ...)?
Спасибо.
Ответы 3
Если компонент работает под управлением x64, он не может загрузить 32-разрядный COM-сервер в процессе, потому что это неправильный тип процесса. Возможны несколько решений:
Если можете, создайте 64-разрядную версию кода COM (которая, конечно, зарегистрируется в 64-разрядном реестре). Это самое чистое решение, но оно может оказаться невозможным, если у вас нет кода для COM-сервера.
Запустите свой .NET-компонент как 32-разрядный x86 вместо x64. Я предполагаю, что вы уже рассматривали и почему-то отвергли это.
Разместите компонент COM вне процесса с помощью COM суррогат DLLhost.exe. Это сделает вызовы COM-сервера намного медленнее (теперь они будут межпроцессными сообщениями Windows, а не вызовами собственных функций), но в остальном будет прозрачным (вам не нужно делать ничего особенного).
Вероятно, это не вариант, если серверу требуется настраиваемый прокси-заглушка вместо использования обычного oleaut32 (хотя и очень редко), поскольку 64-разрядная версия прокси недоступна. Пока он может использовать обычный маршалинг OLE, вы можете просто зарегистрируйте его для суррогатной активации.
@puetzk в моем случае я использую стороннюю dll, которая устанавливается как часть другого приложения. Я не контролирую сборку. В этом случае, как я могу использовать суррогатную функцию COM? Спасибо
@MeTitus вам придется добавлять записи в реестр самостоятельно, и согласование версий может быть непросто, но это все еще возможно.
@puetzk В итоге я выбрал другой путь. Спасибо за ответ. Счастливого Рождества.
Это ваш COM-компонент размещен на COM-сервере (то есть в отдельном процессе), тогда вам не нужно будет делать ничего особенного, поскольку подсистема COM будет удалять ваши вызовы из вашего приложения x64 в приложение X86 и обратно.
Если ваш компонент является внутрипроцессным COM-компонентом, вам придется переосмыслить ситуацию, поскольку 64-битный процесс не может использовать 32-битный COM-компоненты процесса. Вы можете заставить свой сервер работать под x86, чтобы вы могли получить доступ к компонентам (они оба будут 32-битными процессами). Если вы не хотите этого делать, вам нужно будет проверить, есть ли x64-разрядная версия компонентов COM, которые вы используете.
Я нашел это решение, Работа с устаревшими 32-битными компонентами в 64-битной Windows см. В статье:
• Преобразование типа проекта из незавершенного в внепроцессный
• Использование COM + в качестве хоста (это работает для меня)
• Использование dllhost в качестве суррогатного хоста
Спасибо. Но ссылка сейчас мертва. Итак, я поискал в веб-архиве, чтобы найти документ 64-разрядная программа предварительной оценки, том I, выпуск 7 - Работа с устаревшими 32-разрядными компонентами в 64-разрядной Windows
# 1 невозможно, так как нет версии x64. # 2 побеждает цель работы на x64. №3 отлично поработал. Мы можем жить с хитами производительности здесь, пока не получим новую версию библиотеки. Спасибо за вашу помощь.