Межпроцессное взаимодействие C# <-> интерпретатор Lua

Приветствую! Сейчас разбираюсь с задачей управления внешним Windows-приложением с интерпретатором Lua. Это "костыльная" система, альтернатив которой нет, потому не спрашивайте "зачем" - просто "надо". Мне не хватает знаний по организации межпроцессного взаимодействия, потому прошу совета. Сейчас объясню архитектуру и в чём "затыка".

1. Целевое приложение Win64 запускает в дочернем потоке интерпретатора скрипт Lua.
2. Скрипт Lua загружает мою DLL, написанную на C++. Код пишется с использованием статических библиотек разработчика интерпретатора Lua (*.lib, *.h).
3. Управляющее приложение С# должно взаимодействовать с целевым приложением (1) через библиотеку DLL.

Допустим, я реализую в моей DLL базовый механизм двустороннего взаимодействия с целевым приложением. Но сама логика обработки данных целевого приложения не тривиальна и к тому же требует обращения к БД. Поэтому реализовывать весь код на C++ в самой DLL видится крайне неудобным вариантом. Было бы удобно "засунуть" в DLL необходимые интерфейсные методы взаимодействия с целевым приложением, а всю логику вынести в приложение C# (допустим, консольное). Проблема в том, что приложение C# будет работать в одном процессе, а DLL будет загружена целевым приложением в другом процессе, а потому напрямую обратиться к методам в DLL скорее всего не получится. Или есть варианты?

Мне видится необходимым реализовать такие сценарии:
1. Синхронный вызов из приложения C# функции в DLL с возвратом параметров. Для возврата массивов данных можно использовать MemoryFile, заполняемые в DLL.
2. Синхронный обратный вызов из DLL функции в C# с передачей параметров. Для передачи массивов данных использовать MemoryFile, заполняемые в DLL.

Существуют ли разумные способы безопасно реализовать такие сценарии?

PS: Не хотелось бы идти по альтернативному варианту и помещать всю логику в функции в БД, вызываемые из DLL...

0

Сообщение от Tupiel Reuschin При загрузке DLL на C++ она инициализирует рантайм CLR, грузит управляемую .dll #6

Это ты про что? Кто кого инициализирует?

0

Сообщение от Tupiel Reuschin При загрузке DLL на C++ она инициализирует рантайм CLR, грузит управляемую .dll #6, выходит (обратно в Lua).

Одно из условий написания dll на C++ для капиталистического приложения - это отключение поддержки CLR-среды (писал об этом выше). Ради эксперимента попробовал нарушить это правило. На этапе сборки компилятор уже ругнулся предупреждением, что образ состояния (капиталистического приложения) не может быть изменён. Этот образ передаётся в DLL для взаимодействия (аля свой CLR). DLL загрузилась в приложение и ожидаемо подвисло. В общем, надо без CLR.

0

Сообщение от andreybs1 Поясните, что здесь имеете ввиду... Проект на C++ собирается в dll. А как предполагается включить в состав этой dll программу на C#?

За плюсы не шарю, поясню как это можно на C#

вариант 1

Просто добавляем зависимость и копирование exe в выходной каталог. После этого мы можем сделать следующее в коде:
- получить путь к dll С++
- относительно этого пути найти и запустить C# exe

по сути это просто организация билда проектов, чтобы всё было в куче.


вариант 2

Внедряем ресурс внутырь dll. По сути это как файл внутри файла. В момент "запуска" C++ либы внутри основного приложения, мы копируем куда-либо нужный нам C# exe и запускаем его. Есть ли resources для C++ либ -- без понятия, но это легко можно свести к обычному массиву байт или строке base64 (главное не держать в памяти на постоянке).

Более надёжный контроль соответствия версий, но куча возки с "распакуй/зачисть".

--------

Я бы в первую очередь рассматривал первый вариант. Ну и такой подход не является единственно верным. Вполне допускаю что в ряде случаев удобней будет иметь файл-конфигураций для C++ dll, в котором будет указываться путь к C# exe.

0

Сообщение от andreybs1 Одно из условий написания dll на C++ для капиталистического приложения - это отключение поддержки CLR-среды (писал об этом выше).

Потому я вам и говорил про третий проект с C++/CLI, который и будет всё транслировать в/из NET.

0