我们在.NET Framework上有一个项目，该项目引用了Fico Xpress求解器dll。该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中搜索的，该LD_LIBRARY_PATH设置为/ opt / xpressmp / lib /，由/ opt设置）安装手册中指定的/xpressmp/bin/xpvars.sh脚本。此文件夹包含所有.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（只要它位于LD_LIBRARY_PATH中的路径之一，我们就可以将其放置在任何地方），该文件指向/ opt中的libxprb.so文件。 / 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已成功加载。
本文收集自互联网，转载请注明来源。
如有侵权，请联系 [email protected] 删除。
我来说两句