Лучший способ вызова 32-разрядного неуправляемого кода из 64-разрядного управляемого кода с использованием оболочки управляемого кода

Question

Частота, с которой я сталкиваюсь с ситуацией, когда мне приходится вызывать собственный 32-битный код из управляемого 64-битного процесса, увеличивается, так как 64-битные машины и приложения становятся преобладающими.Я не хочу отмечать мое приложение как 32-разрядное, и я не могу получить 64-разрядные версии вызываемого кода.

Решение, которое я в настоящее время использую, состоит в создании COM-оболочек C ++ COM, которыезагружен вне процесса для выполнения 32-битных вызовов из 64-битного процесса.

Это решение COM shim хорошо работает, а межпроцессные вызовы обрабатываются COM за кулисами, что сводит к минимуму издержки этого подхода.

Однако я хотел бы сохранить все новые разработки, которые мы предпринимаем с использованием C #, и поинтересовался, существуют ли какие-либо фреймворки, которые минимизируют накладные расходы на это.Я посмотрел на IPCChannel, но чувствую, что этот подход не такой аккуратный, как решение COM shim.

спасибо, Эд

Answer 1

У меня была такая же проблема, и я решил использовать remoting . В основном проект состоял из:

• Независимая от платформы CalculatorRemote.dll библиотека с
  • CalculatorNative внутренний статический класс с методами x32 P / Invoke
  • RemoteCalculator класс, полученный из MarshalByRefObject, который использовал нативные методы из CalculatorNative;
• Основная независимая от платформы библиотека C # (например, Calculator.dll), ссылающаяся на CalculatorRemote.dll, с классом Calculator, который частным образом использовал синглтон класса RemoteCalculator для вызова функций x32, где это необходимо;
• x32 консольное приложение, которое размещало RemoteCalculator из CalculatorRemote.dll для потребления по Calculator.dll через IpcChannel.

Таким образом, если основное приложение запускалось в режиме x64, оно порождало хост-приложение RemoteCalculator и использовало удаленный экземпляр RemoteCalculator. (Когда в x32 он просто использовал локальный экземпляр RemoteCalculator.) Сложная задача - сказать приложению калькулятора-хоста о завершении работы.

Я думаю, что это лучше, чем использование COM, потому что:

• Вам не нужно нигде регистрировать COM-классы;
• Взаимодействие с COM должно быть медленнее, чем удаленное взаимодействие .NET;
• Иногда, если что-то идет не так на COM-стороне, вам необходимо перезапустить приложение, чтобы восстановиться после этого; (возможно я просто не очень знаком с COM)
• При работе в режиме x32 не будет никакого снижения производительности при удаленном взаимодействии - все методы будут вызываться в одном и том же домене приложений.

Answer 2

Практически единственный ответ - вне процесса коммуникации.Вы можете создать .NET-проект, который представляет собой 32-разрядный исполняемый файл, который выполняет все 32-разрядные вызовы и обменивается ими с помощью сообщений Windows, WCF, именованных каналов, файлов с отображенной памятью (4.0) и т. Д.Вот как Paint.NET выполняет WIA (Windows Imaging Acquisition) из 64-битного процесса.

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