Comments 7
Не знаком с OpenCV, но, кажется, со стороны C# можно было вызывать методы из DLL?
Полагаю, что можно использовать OpenCVSharp
Namespace OpenCvSharp (shimat.github.io)
shimat/opencvsharp: OpenCV wrapper for .NET (github.com)
Вероятно, имеет смысл обратить внимание на Silk.NET
dotnet/Silk.NET: The high-speed OpenGL, OpenCL, OpenAL, OpenXR, GLFW, SDL, Vulkan, Assimp, WebGPU, and DirectX bindings library your mother warned you about. (github.com)
Есть ещё EmguCV (https://www.emgu.com/wiki/index.php/Main_Page). А то, что предлагает автор... ну мягко говоря, является изобретением велосипеда и не должно применяться в промышленных решениях практически никогда (пожалуй только если не стоит задача интеграции с дремучим легаси без поддержки - тогда придётся подстраиваться). Начинать же новый проект с лютых костылей - это путь в один конец
Если стоит задача связать именно два приложения (а не встроить библиотеку), то есть следующие опции:
любое средство для удалённого вызова (тут можно остановиться на grpc или http) - по сути сразу получаем распределённую систему из коробки, которая может работать и локально тоже
именованные каналы, чистый сокет и т.п. (требует разработки собственного протокола обмена, поэтому сложно, да еще и платформозависимо в общем случае)
обмен через файл (имеет место быть в некоторых сценариях), тогда обычно родительский процесс вызывает дочерний с аргументами вида "пиши сюда", дожидается окончания работы и обрабатывает файл с результатом
Для встраивания нативной библиотеки единственный промышленный путь - это использование PInvoke с маршаллингом типов (https://learn.microsoft.com/ru-ru/dotnet/standard/native-interop/pinvoke). В результате может получиться производительно, но в нетривиальных случаях придётся повозиться. Или, как написано выше, стоит обратить внимание на уже готовые обёртки, которые всю сложность вызова нативного кода прячут внутри
Можно приложение Win-Forms и на С++ написать-переписать и вообще никаких проблем не будет.
Через сохранение в файл;
Корректным чтением из другого типа;
Простейшими частями.
Вы бы почитали какую-нибудь документацию про возможности взаимодействия С# с С++ длл-ками, IPC,... Или посмотрели бы как люди делают, а то получается как в анекдоте: чукча не читатель, чукча писатель.
Мне кажется, Вам стоит изучить Программирование .NET с использованием C++/CLI.
Предложенные ранее grpc, http, именованные каналы, чистый сокет и т.п (включая обмен через файл) - суть обмен через сериализацию/десериализацию.
Вы пошли по правильному пути - прямое чтение из неуправляемой памяти. Как раз проблемы обмена с неуправляемой памятью из среды CLR и решает технология C++/CLI. Успехов!
Мой опыт в переводе между типами С++ и С#