C #: ссылка или использование .so файлов в .NET Core в Linux - PullRequest
0 голосов
/ 04 июля 2018

У нас есть проект на .NET Framework, который ссылается на DLL-файл Fico Xpress. Необходимые DLL -

  • Xprb.dll
  • Xprbdn.dll
  • Xprsdn.dll

Поскольку нет доступных пакетов nuget для использования Fico Xpress Solver, мы установили Fico Xpress Solver и скопировали эти dll из каталога установки в нашу локальную папку с именем lib внутри папки проекта и добавили ссылку на путь к эти DLL находятся внутри папки lib. Поэтому при компиляции проект использует для компиляции ссылку на эти библиотеки DLL (присутствующие в папке lib ). Этот проект успешно строится. Когда наш проект вызывает Fico Xpress Solver, указанные выше необходимые dll используются из установочного каталога , доступ к которому возможно через переменные окружения (DLL-файлы в локальной папке предназначены только для успешного выполнения. компиляция кода, и мы могли бы указать на фактический каталог установки Fico Xpress Solver, но мы поместили dll в папку lib , чтобы мы могли добавить ее в SVN), и проект успешно выполняется с использованием Fico Xpress Solver.

Теперь мы перенесли проект на .NET Core, чтобы запустить его на компьютерах с Linux. Поэтому мы установили Fico Xpress Solver на компьютер с Linux и проверили, была ли установка успешной, используя исполняемый файл оптимизатора в папке / opt / xpressmp / bin / (это каталог установки по умолчанию для компьютеров linux). Установка прошла успешно, и Fico Xpress Solver работает правильно (проверил, используя метод, указанный на их сайте).

Когда мы собираем проект, он успешно компилируется, так как он все еще ссылается на необходимые библиотеки DLL внутри локальной папки lib . Но когда наш проект вызывает Fico Xpress Solver во время выполнения, он терпит неудачу, так как не может загрузить требуемые библиотеки DLL (которые он, вероятно, искал в LD_LIBRARY_PATH , который установлен в / opt / xpressmp / lib / в соответствии со сценарием / opt / xpressmp / bin / xpvars.sh , указанным в руководстве по установке. Эта папка содержит все файлы .so и нет dll файлов.) Ошибка, как показано ниже -

Невозможно загрузить общую библиотеку 'xprb.dll' или одну из ее зависимостей. Чтобы помочь диагностировать проблемы с загрузкой, рассмотрите возможность установки Переменная среды LD_DEBUG: libxprb.dll: не удается открыть общий объект файл: нет такого файла или каталога

Мы не уверены, что подход, который мы используем, то есть использование dll для компиляции и запуска, верен или нам нужно каким-то образом использовать файлы .so для компиляции и запуска проекта. Поскольку код создавался успешно, мы ожидали, что он запустится, но общие объектные файлы не найдены.

Может ли кто-нибудь указать способ использования Xpress solver в Linux или некоторые общие рекомендации, которые необходимо соблюдать при использовании того же программного обеспечения сторонних производителей в Windows, а затем в Linux. Нужно ли нам менять код или добавлять ссылку на .so вместо .dll files

Является ли DllImport единственным способом сделать это (предлагается в разных блогах)

1 Ответ

0 голосов
/ 09 июля 2018

Мы наконец нашли способ сделать это, но мы не уверены, что он будет применим ко всем, и он может не решить чью-то проблему. Здесь идет наш подход -

Как уже упоминалось в вопросе, xprb.dll не удалось загрузить, поскольку libxprb.dll было тем, что он искал в каталоге Xpress lib (/ opt / xpress / Библиотека /). Но после установки Xpress в Linux, установка содержала только .so файлы и не .dll файлы .

В некоторых блогах предлагалось использовать метод DllImport для загрузки файлов .so, а затем вызывать методы. Мы не пробовали эти методы, так как искали что-то более простое, чем это.

После решения проблемы мы обнаружили, что только если мы укажем загрузку разделяемых библиотек каким-либо образом установленным .so-файлам, это может сработать. Таким образом, ситуация была таковой в нашем конкретном случае -

  • У нас не было libxprb.dll в папке / opt / xpressmp / lib /
  • У нас был файл libxprb.so вместо libxprb.dll в папке / opt / xpressmp / lib / (если бы у нас не было этого файла, мы, вероятно, не знали бы, какой другой .so файл для использования)

Таким образом, мы создали файл символической ссылки libxprb.dll в папке / opt / xpressmp / lib / (которую мы, вероятно, могли бы разместить в любом месте, если бы он был в одном из путей в LD_LIBRARY_PATH), который указал на файл libxprb.so в папке / opt / xpressmp / lib / с помощью команды -

ln -s /opt/xpressmp/lib/libxprb.dll /opt/xpressmp/lib/libsprb.so

Так что теперь, когда xprb.dll был загружен, он искал libxprb.dll, который, в свою очередь, указывал на файл libxprb.so (поскольку libsprb.dll была символической ссылкой на libxprb.so) и, следовательно, xprb.dll был успешно загружен.

...