Как связать файл.so с управляемой DLL с помощью моно
Я пишу программу для встроенного Linux на процессоре ARM в.net, которая использует моно для выполнения. Я обнаружил, что могу просто скомпилировать на своем компьютере архитектуру x86 или x64, скопировать каталог Debug в linux и запустить программу, используя моно myProgram.exe. Программа работает идеально, как это, и моно, кажется, заботится о несоответствии архитектуры. Это было верно до сегодняшнего дня, когда я попытался включить внешнюю нативную DLL.
У меня есть как x86, так и x64-битная архитектура внешней DLL, и обе прекрасно работают в среде рабочего стола. У меня есть класс shim, который использует [DllImport] для загрузки внешних функций. Однако, когда я пытаюсь сделать это на встроенном Linux с Mono, я получаю исключение BadImageFormat. Я предполагаю, что Mono каким-то образом переводит скомпилированные библиотеки DLL в исполняемый файл при запуске, но не делает то же самое для внешних.
Немного другой информации: 1. У меня нет исходного кода для внешней библиотеки. У меня есть x86, x64 и библиотека.so. 2. Я попытался создать управляющую оболочку C++, которая обращается к.so, но не может заставить его скомпилировать на рабочем столе, так как Windows не распознает файл.so.
Некоторые мысли: 1. Есть ли способ встроить нативную DLL в управляемую, чтобы Mono также перенесла нативную DLL? 2. Могу ли я связать файл.so с управляемым проектом C++? 3. Есть ли способ сказать Моно, чтобы включить эту Dll во время выполнения?
В конечном итоге я ищу решение, которое включено в исполняемый файл, который позволяет мне просто запустить его, как я делал раньше, и управлять собственной системой.
1 ответ
Если у вас есть все.dll и.so файлы для Windows и Linux, вы, вероятно, можете использовать функцию dll maps в Mono. ( https://www.mono-project.com/docs/advanced/pinvoke/dllmap/), которые используются для сопоставления имен DLL Windows с именами Linux.
.Net не признает это, но Моно делает.