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

Question

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

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

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

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

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

спасибо, Ed

14

c# .net 32bit-64bit managed

задан Edward 7 June 2010 в 12:51

2 ответа

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

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

5

ответ дан 1 December 2019 в 14:43

Другие вопросы по тегам:

c# .net 32bit-64bit managed

Похожие вопросы:

score 7 · Accepted Answer

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

Платформенно-независимой CalculatorRemote.dll библиотеки с
- Внутренний статический класс CalculatorNative с методами x32 P / Invoke
- Класс RemoteCalculator , производный от MarshalByRefObject , который использовал собственные методы из CalculatorNative ;
Main платформенно-независимая библиотека 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 удаленное взаимодействие не приведет к снижению производительности - все методы будут вызываться в одном домене приложений.