C#:在Linux上的.NET Core中引用或使用.so文件 [英] C# : Referencing or using .so files in .NET Core on Linux

查看:1556
本文介绍了C#:在Linux上的.NET Core中引用或使用.so文件的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我们在.NET Framework上有一个项目,该项目引用了Fico Xpress求解器dll.该dll的要求是–

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

由于没有nuget软件包可用于Fico Xpress Solver,因此我们安装了Fico Xpress Solver,并将这些dll从安装目录复制到项目文件夹中名为 lib 的本地文件夹中,并添加了路径参考到lib文件夹中的这些dll.因此,在编译时,项目将使用这些dll(位于 lib 文件夹中)的引用进行编译.该项目成功构建.当我们的项目调用Fico Xpress Solver时,将从安装目录中使用上述必需的dll,该目录可能通过环境变量访问(本地文件夹中的dll只是为了成功编译代码,我们可以将其指向实际的Fico Xpress Solver安装目录,但我们将dll放在 lib 文件夹中,以便我们可以将其添加到SVN中),并且使用Fico Xpress解算器.

现在,我们已将项目移植到.NET Core,以便在Linux机器上运行该项目.因此,我们在Linux计算机上安装了Fico Xpress Solver,并通过使用/opt/xpressmp/bin/文件夹(这是Linux计算机的默认安装目录)中的优化程序可执行文件来测试安装是否成功. .安装成功,并且Fico Xpress Solver能够正确运行(使用其网站上提供的方法进行了检查).

在构建项目时,它仍然可以成功编译,因为它仍然引用本地 lib 文件夹中所需的dll.但是,当我们的项目在运行时调用Fico Xpress Solver时,它失败了,因为它无法加载所需的dll(它可能是在 LD_LIBRARY_PATH 中搜索的,该文件设置为/opt/由安装手册中指定的/opt/xpressmp/bin/xpvars.sh 脚本设置的xpressmp/lib/.此文件夹包含所有 .so 文件,没有 dll 文件.)错误如下–

无法加载共享库'xprb.dll'或其依赖项之一. 为了帮助诊断加载问题,请考虑设置 LD_DEBUG环境变量:libxprb.dll:无法打开共享库 文件:没有这样的文件或目录

我们不确定我们使用的方法(即使用dll来编译和运行)是否正确,或者我们是否必须使用某种方式使用 .so 文件来编译和运行项目.代码成功构建后,我们希望它能够运行,但是找不到共享的对象文件.

有人可以指定在Linux上使用Xpress求解器的方法,还是在Windows上然后在Linux上使用相同的第三方软件时需要遵循的一些一般准则.我们是否需要更改代码或添加对 .so 而不是 .dll 文件

的引用

DllImport 是做到这一点的唯一方法(建议在不同的博客上使用)

解决方案

我们终于想出了一种方法,但是我们不确定该方法是否适用于所有人,并且可能不能解决某人其他的问题.我们的方法来了-

如问题中所述,无法加载 xprb.dll ,因为 libxprb.dll 是它在Xpress lib目录(/opt/xpress/lib/).但是在Linux中安装Xpress后,安装中仅包含 .so文件,没有.dll文件.

有些博客建议使用DllImport方法加载.so文件,然后调用这些方法.在寻找比这更简单的方法时,我们没有尝试过这些方法.

对问题进行投资后,我们发现只有将共享库的加载指向以某种方式安装的.so文件时,它才可能起作用.因此,在我们的特定情况下情况就是这样-

  • 我们在/opt/xpressmp/lib/文件夹中没有libxprb.dll
  • 我们在/opt/xpressmp/lib/文件夹中有libxprb.so文件而不是libxprb.dll (如果我们没有此文件,则可能不会知道其他文件.以便使用)

因此,我们在/opt/xpressmp/lib/文件夹中创建了一个符号链接文件libxprb.dll (只要它位于LD_LIBRARY_PATH中的路径之一,我们就可以将其放置在任何位置).使用命令指向/opt/xpressmp/lib/文件夹中的libxprb.so 文件-

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

因此,现在加载xprb.dll时,它会查找libxprb.dll,后者又指向libxprb.so文件(因为libsprb.dll是指向libxprb.so的符号链接),因此xprb.dll已成功加载./p>

We have a project on .NET Framework that references the Fico Xpress solver dll. The dll’s required are –

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

As no nuget packages are available for using Fico Xpress Solver, we installed the Fico Xpress Solver and copied these dll’s from the installation directory to our local folder named lib inside the project folder and added path reference to these dll’s inside the lib folder. So when compiling, the project uses the reference of these dll’s (present in the lib folder) to compile. This project successfully builds. When our project calls the Fico Xpress Solver, then the above required dll's are used from the installation directory which is probably accessed through the environment variables (the dll's in local folder are just for successful compilation of code and we could have pointed it to the actual Fico Xpress Solver installation directory but we put the dll's in lib folder so that we can add it to the SVN) and the project runs successfully using the Fico Xpress Solver.

Now, we have ported the project to .NET Core so as to run the same on Linux machines. So we installed Fico Xpress Solver on the Linux machine and tested whether the installation was successful by using the optimizer executable inside the /opt/xpressmp/bin/ folder (this is the default installation directory for linux machines). Installation is successful and the Fico Xpress Solver runs correctly (checked it using the method given on their website).

When we build the project, it compiles successfully, as it still refers to the required dll’s inside the local lib folder. But, when our project calls the Fico Xpress Solver during run time, it fails as it could not load the required dll’s (which it was probably searching in the LD_LIBRARY_PATH which is set to /opt/xpressmp/lib/ as set by the /opt/xpressmp/bin/xpvars.sh script which was specified in the installation manual. This folder contains all the .so files and no dll files.) The error is as below –

Unable to load shared library 'xprb.dll' or one of its dependencies. In order to help diagnose loading problems, consider setting the LD_DEBUG environment variable: libxprb.dll: cannot open shared object file: No such file or directory

We are not sure whether the approach we are using i.e. using dll's to compile and run is correct or whether we have to some how use the .so files to compile and run the project. As the code was building successfully, we expected it to run, but the shared object files are not found.

Can someone please specify a way to use Xpress solver in linux or some general guidelines that need to be followed when using the same 3rd party software on windows and then on linux. Do we need to change the code or add reference to .so rather than the .dll files

Is DllImport the only way to do this (suggested on different blogs)

解决方案

We finally figured out a way to do so but we are not sure it will be applicable to everybody and it might not solve somebody else's problem. Here goes our approach -

As mentioned in the question, the xprb.dll could not be loaded because libxprb.dll was what it was searching for in the Xpress lib directory (/opt/xpress/lib/). But after installing the Xpress in Linux, the installation contained only .so files and no .dll files.

There were some blogs which suggested using DllImport method to load the .so files and then call the methods. We didn't try those methods as we were looking for something simpler than that.

After investing the problem we found that only if we point the loading of shared libraries to somehow the installed .so files, it might work. So the situation was as such in our specific case -

  • We did not have a libxprb.dll in the /opt/xpressmp/lib/ folder
  • We had libxprb.so file instead of libxprb.dll in the /opt/xpressmp/lib/ folder (if we didn't have this file we probably wouldn't have known which other .so file to use)

So we created a symlink file libxprb.dll in /opt/xpressmp/lib/ folder (which we probably could have placed anywhere as long as it was in one of the path in LD_LIBRARY_PATH) which pointed to the libxprb.so file in /opt/xpressmp/lib/ folder using the command -

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

So now when xprb.dll was loaded, it looked for libxprb.dll which in turn pointed to libxprb.so file (as libsprb.dll was a symlink to libxprb.so) and hence xprb.dll was loaded successfully.

这篇关于C#:在Linux上的.NET Core中引用或使用.so文件的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆